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ABSTRACT 



This thesis reviews the development and application of 
current non-tactical shipboard ADP systems in the U.S. Navy, 
and provides an analysis of each systems' strengths and 
weaknesses. The primary focus of this review includes 
Perq/ZOG, WANG installations, and SNAP II. The 
methodologies of procurement, development and implemenation 
vary as widely as the scope and complexity of the various 
systems. This analysis provides insight into some primary 
management issues, limitations, and constraits encountered 
in providing non-tactical automatic data processing to the 
fleet . 
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I. INTRODUCTION 



"For want of a nail the shoe is lost, for want of a shoe 
the horse is lost, for want of a horse the rider is 
lost". [Ref. 1] 

These familiar words from an old verse still ring true 
today, except with the U.S. Navy, the proverbial nail has 
been replaced by the small, modern, non-tactical computer. 

Since the late 1970's, there has been a proliferation of 
computers on board the ships and vessels of the U.S. Navy, 
which has served to revolutionize the processing of 
information at sea. These small processers have generally 
increased the productivity of ship's administrative 
personnel by allowing each man to produce more information 
of a higher quality than was previously possible in a manual 
mode. They have also provided the Commanding Officer and his 
key assistants with more timely information on which to base 
their everyday management decisions. 

Along with these benefits, the introduction of the small 
non-tactical computer into the shipboard environment has 
exacerbated the ongoing concerns of security and 
standardization, while introducing many new issues that must 
be dealt with, such as control of computer resources and 
dependency on systems that could cease to function at any 
time in the harsh at-sea environment of a ship. 

The objective of this thesis is not to identify and 
analyze all the systems presently implemented on board Naval 
ships, but to survey a few of them in regards to their 
architecture, benefits, and unique technical and managerial 
problems . 

This thesis focuses on three distinct computer 
installations that are currently implemented on board U.S. 
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Naval ships. Chapter Two looks at a system of Perq 
minicomputers installed on board the U.S.S. Carl Vinson that 
run an experimental menu-driven, distributed database called 
ZOG. ZOG was developed at Carnegie- Mellon University with 
support from both the Office of Naval Research (ONR) and the 
Defense Advanced Research Agency (DARPA) . Chapter Three 
addresses the WANG VS-100 which is also installed on board 
the U.S.S. Carl Vinson. It was selected for inclusion in 
this thesis because it is an off-the-shelf commercial system 
that has been installed and operated without being 
specifically designed or altered for the shipboard 
environment. This system was also developed without the 
benefit of government support. Chapter Four discusses the 
SNAP system, which is presently being placed on board all 
naval ships. This system comes in two versions, the 
Honeywell SNAP I system is for large ships, and the Harris 
SNAP II system is for smaller ones. Both of these systems, 
which are centrally procured and managed by the Navy, have 
been specifically ruggedized for a shipboard environment. 
Chapter Five consolidates some of the conclusions that have 
been drawn from the other chapters. 

While this thesis does not attempt to analyze the whole 
spectrum of problems concerning non-tactical automation that 
is now being addressed in the fleet, it does attempt to 
survey many of them from the viewpoint of the professional 
naval officer. However, a concerted effort has been made 
to define or describe terms unique to the Navy or shipboard 
life for those readers without an appropriate naval 
background . 
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1 1 . PERO 



A. INTRODUCTION 

In 1981, a non-tactical computer system consisting of 
twenty-eight Perq minicomputers and the prototype software 
called ZOG was installed on board the Navy's new aircraft 
carrier, the U.S.S. CARL VINSON. These minicomputers were 
state-of-the art technology, offering the user a choice 
between mouse technology or a detachable keyboard for 
accessing the ZOG system. E^ch Perq minicomputer was also 
configured with a hardware graphics tablet for the mouse, 
one megabyte of random access memory, four thousand bytes of 
writable control storage, and a twenty-four megabyte 
Winchester hard disk storage drive. All the Perq 
minicomputers were connected in a local area network by a 
lOmz Ethernet. 

The heart of this system was ZOG, an experimental, 
human- computer interface conceived and developed at 
Carnegie-Mellon University in the early 1970's. It is the 
transfer of ZOG technology from the research laboratory of 
academe to the operational shipboard environment of the 
U.S.S. CARL VINSON that will be the focus of this chapter. 

B . BACKGROUND 

ZOG was initially conceived and developed in 1972 as 
part of a summer workshop held at Carnegie-Mellon University 
(CMU) for cognitive psychologists studying simulation 
[Ref. 2]. The original intent of ZOG was to provide a 
system that would allow new users to access and explore 
large complex programs. Although the concept proved 
workable, lack of a fast terminal input/output device made 
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the actual system too slow. At that time, state of the art 
terminal technology was limited to 300 baud with hardcopy 
output. Hence, the system was shelved until more advanced 
hardware and communication technology became available. 

In 1975 Alan Newell and George Robertson, two of the 
original developers of ZOG, served on a technical advisory 
committee for PROMIS (Problem Oriented Medical Information 
System); a system strikingly similar to the ZOG concept, but 
which utilized the latest in hardware technology. PROMIS was 
conceived by DR. Lawrence Weed of the University of Vermont 
Medical School. It was a combination of a management 
information system and a menu guidance system that was 
billed as a comprehensive approach to health care. [Ref. 3] 
PROMIS used a Sperry-Univac V77-600 minicomputer with 250k 
ram, three Control Data Corporation Storage Module Drives ( 
250 megacharacters per spindle ) and associated peripherals 
per node. The user interfaced the computer via a high speed 
( approximately 1/2 second access time) CRT terminal, which 
incorporated a touch sensitive screen as well as a standard 
keyboard [Ref. 4]. 

This demonstrated use of modern high speed terminal 
technology in the PROMIS system resulted in revived interest 
in ZOG at Carnegie-Mellon University. With support from both 
the Office of Naval Research (ONR) and the Defense Advanced 
Research Agency' (DARPA), newer versions of ZOG were 
developed and brought up on the university's PDP-10, first 
using a Tops 10 and then a TOPS 20 operating system. ZOG was 
also installed on the university's experimental 
multiprocessor, C.MMP. By 1980 Carnegie-Mellon researchers 
were successfully running ZOG on a new Ethernet local area 
network, which connected the university's PDP-lOs, Xerox 
Altos, and new DEC Vax computers. [Ref. 5] 

There were two occurrences in 1980 that had major impact 
on ZOG's development. One was the implementation of SPICE, 
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(Scientific Personal Integrated Computing Environment) as a 
research project at Carnegie-Mellon. Since several of the 
researchers working on SPICE had also worked on ZOG, it was 
inevitable that the two systems would be closely affiliated. 
Informal relationships that occurred because of this close 
affiliation were reinforced as a result of a conscious 
decision made by researchers at Carnegie-Mellon to 
eventually integrate all software projects at the university 
with SPICE. As a direct result of this decision, the Perq 
minicomputer from the Three Rivers Computer Corporation that 
was selected for initial SPICE implementation, was 

ultimately selected for ZOG when it was moved from the 
research to the operational arena. [Ref. 6] 

The other occurrence was a visit to Carnegie-Mellon by 
Navy Captain Richard Martin, the prospective commanding 
officer of the nuclear powered aircraft carrier, U.S.S. 
CARL VINSON, then under construction in Newport News, 

Virginia . 

Captain Martin was visiting several ONR research sites 
throughout the country to familiarize himself with the 
latest developments in various technical areas. His purpose 
at Carnegie-Mellon was to ascertain what advanced computer 
technology was available that might prove useful on board 

the U.S.S CARL VINSON. His initial encounter with ZOG at 

Carnegie-Mellon convinced Captain Martin that a marriage 
between the new software technology and the U.S.S. CARL 
VINSON would serve two purposes. 

1. It would supply the ONR/DARPA supported research at 
CMU with an operational test bed, and 

2. It would give U.S.S CARL VINSON the latest in 
computer technology to help manage the carrier's 
extensive administration requirements in the areas of 
management, maintenance, and planning. 
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To evolve ZOG to a point where it could be implemented 
on board U.S.S. CARL VINSON, a formal ZOG Technological 
Demonstration Project was established in March 1981. Its 
goals were to get fleet personnel involved as soon as 
possible in the ZOG project, to accelerate application 
development to more closely conform with U.S.S CARL VINSON's 
commissioning and trial schedules, and to expand the 
functional span and quality of the final product [Ref. 7]. 
Three shipboard areas were initially selected to use ZOG. 
These included on-line creation of the Ship's Organization 
and Regulations Manual (SORM), administration planning and 
evaluation, and weapons elevator maintenance training. 

C. THE NATURE OF ZOG 

Thus far, we have only briefly described the evolution 
of the Perq/ZOG system from its beginnings at 
Carnegie-Mel Ion University in the early seventies, to the 
establishment of a formal ZOG Technological Project in March 
1981. We have not specifically defined nor completely 
described ZOG. What is ZOG? How does it differ from the 
numerous other software concepts that were being discussed 
and developed in universities, research institutions, and 
commercial laboratories throughout the 1970' s and early 
1980's? These and similar type issues must be discussed 
before ZOG's potential impact can be analyzed and evaluated. 

1 . Essence of ZOG 

ZOG has been described as "a rapid- response , 
large-network, menu-selection computer interface" [Ref. 8], 
In less succinct words, it is an extremely fast, distributed 
data-base that is driven by menus called display frames. 
These display frames are the essence of ZOG. The function of 
a display frame is to present information to the user and 
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allow him to jump to another frame when finished with the 
one he is currently on. With few exceptions, the degree of 
information that can fit on the standard terminal screen is 
the maximum amount of information allowed in one display 
frame. This limitation does not present many problems, 
however. Since the Perq's high resolution screen actually 
allows two full frame menus to be displayed at a time, the 
user does not require a scrolling function when viewing 
data. The first information item on a display frame is the 
frame's title line. It can consist of a variable length 
title and a short summary of the frame's contents. The 
second information item is the frame's text. It further 
expounds on the frame's main point of information. The third 
information section constitutes a list of numbered options. 
An option can consist of the title of a subsequent frame, 
which when activated will move the user to that particular 
frame. Options can also be used like subpoints of the frame 
text as in an outline (Ref. 9], If we envision the entire 
database as a tree structure, and each menu as a parent 
node, we can view the children of each parent node as frames 
accessible through options. A fourth information item on the 
frame is the set of local pads. Local pads are used to 
invoke programs or point to extrinsic information. Using the 
tree analogy, local pads on the menu could point to frames 
or nodes in a totally different tree vice that of the 
frame's children. They are cross reference links. The final 
information item on a display frame consist of the global 
pad set. These pads perform often repeated actions e.g. go 
into edit, go to the previous frame, find information, help, 
etc . 

Thousands of these frames can be connected together 
to form what is called a "subnet". Subnets are functional 
groupings of menus that form some report, program, or other 
entity when interconnected. 
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2 . ZOG and User Integration 



When interacting with ZOG, the user is in one of 
three modes. He is either navigating, invoking a program, 
or editing [Ref. 10]. Navigation is the act of making a 
selection of an option, local pad, or global pad by way of 
the mouse pointing device or keyboard. The system reacts by 
replacing the current display frame with that of the new 
selection . 

Embedded within ZOG are agents (application and 
utility programs) written in the Pascal language. These 
agents are used in planning and document writing, or as 
interface drivers for input/output devices. Because ZOG 
supports a programming environment these programs can be 
written and implemented into the database by the user 
himself . 

If the user desires to invoke an agent embedded 
within ZOG, he usually navigates to a particular display 
frame on which the program is listed as an action item, 
fills in the required parameters, and then selects the 
action. McCracken and Akscyn describe an action item as: 

"A sequence of commands in the ZOG action language -- a 
simple programming language. This language contains 
commands for traversing the network, invoking intrinsic 
utilities, and entering the editor. [Ref. 11] 

The third area of interaction between ZOG and the 
user is editing. Onboard the U.S.S. CARL VINSON, a user has 
the choice of two different editors. The principle editor is 
ZED (ZOG edit). ZED is a frame editor that is used for 
making changes to the database. Its main purpose is to 
provide an instrument for creating new frames, changing 
links between frames, or editing the contents of existing 
frames. ZED can be invoked from any frame via the "edit" 
global pad. A second editor called SLED (slot edit) is also 
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available within ZOG. This editor has proved much easier to 
use than ZED, but unlike ZED, it cannot be used to create 
frames. SLED is designed for use in applications that 
require fast, accurate input or editing of information. It 
is especially useful in running ZOG agents. SLED has a built 
in error-checking capability that matches input dates, 
times, frame, subnets, and other pertinent information 
against its data base to ensure their validity. With its 
pop-up type menu and default value display, SLED allows the 
user to quickly input required parameters for an agent by 
invoking electronic toggle switches with the mouse or 
keyboard. One application that relies heavily on SLED is the 
"expert" system called AIRPLAN. AIRPLAN is used by the air 
operations officer in monitoring and controlling aircraft. 
When aircraft data is loaded into the system it is checked 
against the ZOG database to ensure that relevant information 
concerning the pilot, aircraft, and mission correlates with 
what is in the database. These parameters, as well as the 
parameters required by all agents, are entered by using 
SLED. AIRPLAN will be discussed at a later point in this 
paper . 

D. ZOG AND THE U.S.S. CARL VINSON 

In evaluating a system such as ZOG, several criterion 
must first be established with which the system can be 
measured and compared. Still, regardless of how careful 
these criterion are chosen, a system can seldom be deemed 
either a total failure or a total success. More often than 
not it lies in the proverbial gray area in which it is a 
success in one arena, a failure in a second, and 
indeterminate in a third. 
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1. Criterion for Success 



Criterion used in evaluating 20G will vary with the 
perspective from which it is being viewed, the 
interpretation of common measures, and the individual's 
knowledge of the environment in which the system is 
utilized . 

A battle group commander, for example, may consider 
the system a failure because it cannot use standard software 
already developed and distributed throughout the fleet. An 
individual commanding officer may view this same system as a 
success, because it gives him the information he requires at 
the time he needs it. The user/technician may view the 
system as unsuccessful, because it is difficult to operate 
and maintain. Each observation is valid, yet leads to 
different conclusions. 

One common criterion heavily used in evaluating ZOG 
was usage. Newell stated that "ZOG is a success to the 
extent that it becomes used for actual operations, and to 
the extent that such use continues and expands" [Ref. 12]. 
This supposition was affirmed by Van Matre, Moy, and McCann 
as, "the best measure of system success is the use or 
non-use of the system" [Ref. 13]. While this premise 
appears reasonable, its use should be tempered with a 
thorough knowledge of the environment in which the system is 
utilized, otherwise, erroneous results may occur. 

Low usage of the Perq/ZOG system may not be 
significant on board the U.S.S. CARL VINSON because the ship 
has other non-tactical computer systems that can duplicate 
many of its applications, e.g. WANG-Net, Snap, etc. Also 
there are other less apparent factors that could account 
for this low usage. An example of thes is evident in the 
SORM. (Ship's Organization And Regulations Manual). 
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The SORM is a ship's document that gives detailed 
instructions on the daily routine to be followed by a ship. 
It is developed and tailored by ship's personnel 

specifically for their ship. The SORM is a dynamic document 
that reflects the philosophy of the commanding officer, but 
follows the format and guidelines of the Navy 1 s SORM, 
OPNAVINST 3120.32 (Operational Navy Instruction 3120.32). 
OPNAVINST 3120.32 can function as the ship's SORM with a few 
page insertions and some pen and ink changes, as is often 
done on smaller vessels. Consequently, development of a 
shipboard version is usually of low priority compared to 
more pressing documentation. Therefore, low usage on a SORM 
subnet could lead to an erroneous interpretation and 
conclusion about ZOG's suitability for developing this 
particular type of documentation. In reality, the usage or 
non-usage of this subnet might be more a function of command 
emphasis and priorities on SORM development, than a 
reflection on ZOG. 

2 . Evaluation of the VINSON/ZOG Pro j ect 

Three areas were initially selected for ZOG' s 
implementation on board U.S.S. CARL VINSON. These included 
the SORM, administrative planning and evaluation 
(management), and weapons elevator maintenance training. 
Later, an expert system called AIRPLAN was added along with 
several ad hoc applications. Each of these application areas 
would suffer common problems endemic to either ZOG or the 
Perqs. These problems include the following: 

a. "Difficulty in using the ZED editor" [Ref. 14]. The 
editor has proven awkward and hard to use. Once 
mastered, it requires constant use to maintain 
proficiency. 

b. "ZOG is biased too much toward a breadth-first view" 
[Ref. 15]. This is unnatural in relation to the 



19 



normal way one is taught to think and read. An 
analogy of this problem can be illustrated in reading 
a book. When reading a book, one is taught to read 
the first sentence on the first page, the second 
sentence on the first page, etc., until the first 
page has been read. The reader will then progress 
through the second page, third page and so fourth 
reading in this top to bottom manner. This is reading 
depth first. If one were to instead read the first 
sentence on page one of chapter one, the first 
sentence on page one of chapter two etc., until he 
progressed through the complete book, then return to 
the beginning and do the same for the second 
sentence, this would be breadth first. This type of 
thought process is what is asked of the user in 
reading ZOG subnets. 

c. Hardware/Software problems. During the U.S.S. CARL 
VINSON's 1983 cruise, problems were continually 
experienced with the Perq minicomputers. These 
problems were partly due to the equipment being 
ill-designed for a shipboard environment, and partly 
due to equipment being installed without the benefit 
of shock absorbers to compensate for pitch and roll 
of the ship, or basic voltage protection to ensure 
clean power, e.g. isolation transformers, line 
regulators, line conditioners, uninterruptible power 
supply, etc. Consequently the Perqs and Ethernet 
experienced continual problems with electronic boards 
and other electrical components. 

ZOG itself was a major source of frustration to 
members of the management department. Its personnel were 
expending an inordinate amount of time in debugging the 
system, indicating poor quality control of ZOG software 
received from Mellon Institute. This lack of quality control 
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was probably a direct result of transferring ZOG technology 
from the research environment to an operational environment 
too early in its development cycle. To exacerbate the 
problem even further, management personnel on board the 
U.S.S. CARL VINSON were attempting to integrate code being 
written at both the Mellon Institute development site and 
shipboard operational site. This difficult task was 
attempted under an inflexible set of time constraints with 
poor communication between the two sites. When the ship was 
at sea, it could take up to a month for a mail query to be 
answered . 

a . The SORM 

Nicholas Van Matre, Melvyn Moy and Patrick 
McCann concluded in their evaluation of ZOG that "The SORM 
was not suitable as an organizing element for all functional 
applications as was originally conceived" [Ref. 16]. They 
further found that there was a disproportionate usage of 
SORM subnets, i.e. some portions were meticulously developed 
and were providing extremely useful management support, 
while other portions of the SORM subnet remained nothing but 
shell. 

The rational for this phenomenon was two-fold: 

1. "Time was a limiting factor" [Ref. 17]. By this, 
they mean that Perq/ZOG development was performed by 
shipboard users collaterally with their primary 
responsibilities. These users had to develop SORM 
subnets in their own time after fulfilling their 
foremost shipboard duties. This is closely related to 
command emphasis, which was previously discussed. 

2. The users had difficulty in "instantiating their job 
as a subnet" [Ref. 18]. The user who was an expert 
on the business side of the SORM, also had to perform 
the technical function of fitting and copying his 
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job into the ZOG database. This is a skill that 
requires some expertise in choosing meaningful levels 
of division and a good working knowledge of ZED 
[Ref. 19]. Without this skill, and with limited or 
non-recent training in this area, many users became 
extremely frustrated. 

Besides the above, hardware and software 
problems had a discernible effect on SORM development. The 
management department on board the U.S.S. CARL VINSON had 
completed installing the ZOG shell for SORM subnets before 
the ship's initial cruise in 1983. Because of the size of 
these SORM subnets (over 10,000 frames), the SORM database 
was distributed over four host Perq minicomputers. Four 
other Perqs held read only secondary copies. The other 
twenty Perqs had the capability of accessing this SORM 
database through the Ethernet local area network. During the 
cruise, ship personnel experienced problems with both the 
Ethernet and the Perqs, which precluded reliable access to 
the SORM database by all except the four host computers. 
This in effect limited the number of locations and, 
therefore, the number of people that could access the SORM 
database at one time. To further frustrate the user, several 
other Perq minicomputers ceased to function as the cruise 
progressed. Fewer and fewer computers were available on 
which to run ZOG, thus further impacting SORM development. 
By the end of the cruise there were only nineteen 
functioning Perqs. 

The combination of these problems has served to 
frustrate the user and inhibit online development of the 
SORM. 



b. Weapons Elevator Maintenance Training 

A complex application attempted with ZOG was an 
on-line technical manual for the ship's weapons elevators. 
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This manual was to provide maintenance personnel of the 
ship's weapons department with technical support in 
repairing, maintaining, and operating the ship's weapons 
elevators. Additionally, it was to serve as a training 
device for all members of the G-3 division. The manual 
itself was hosted on three Perq minicomputers that were 
connected to a laser video-disk player and CRT display 
monitor . 

During ship construction in Newport News, 
Virginia, members of the weapons department G-3 division 
made detailed, multiple- view video tapes of each step in 
assembly and installation of the weapons elevators. On 
completion, more color video tapes were made showing the 
elevators in operation with appropriate motion and sound. 
These video tapes were then moved to laser video disks. 
Consequently, a complete pictorial history was made of each 
weapons elevator aboard U.S.S. CARL VINSON. 

Once developed, the user of this system would 
read the on-line narrative portion of the technical manual, 
and then look at the picture display. Like the SORM, all 
material was categorized into three functional ZOG trees. 

1. UNDERSTAND: This section breaks the elevator into 

components, and describes their location and 
function. While this section was easy to comprehend, 
it was very difficult to actually construct a tree. 

2. OPERATE: This is a combination description and 

demonstration of elevator operation. 

3. EVALUATE/MAINTAIN : This provides the technicians with 
preventive maintenance procedures, specification and 
electrical schematics. 

While the on-line elevator maintenance manual 
proved an excellent use of the new ZOG technology, it was 
plagued with both software and hardware problems. The Perq 
computers suffered electronic circuit board problems due to 
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power fluctuations, while the laser video disk player 
experienced alignment problems due to the motion and 
vibration inherent on board ship. In the software arena, a 
great deal of effort was expended in continually debugging 
due to problems between the operating system and ZOG. One 
other area in which the weapons elevator program proved 
deficient was video disk expansion capability. It proved too 
expensive to add to the current disk or make more disks. 
Hence, before completion of the on-line technical manual, 
the video disk literally ran out of space, resulting in 
later additions to the technical manual being narrative only 
[Ref. 20]. 

c. AIRPLAN 

AIRPLAN is an "expert" system that was developed 
as an aid and tool for the air operations officer in 
monitoring and controlling carrier aircraft. It is not a 
part of ZOG, but uses ZOG as an interface system between 
itself and the user. 

The AIRPLAN program is a rule-based, decision 
support system that maintains a summary status on all 
aircraft operationally controlled by the U.S.S. CARL VINSON, 
and recommends actions to be taken as different situations 
arise, e.g. emergency procedures. It is also capable of 
modeling aircraft scenarios without requiring actual 
aircraft launch. 

Before flight operations, daily flight schedules 
and initial status of all aircraft are loaded into the 
AIRPLAN net. This includes such information as mission, 
pilot name, primary and secondary buttons (communication 
frequencies ), and initial fuel and ordinance loads for each 
aircraft. These inputs are loaded using SLED and are 
automatically checked for errors. Output includes a hardcopy 
flight schedule, ordnance loading plan and an emergency 
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landing plan. Once airborne, each aircraft is monitored and 
its real time status is summarily displayed on a Perq 
minicomputer. Included in this display is the amount of 
remaining fuel in pounds and time remaining before certain 
critical decisions must be made, i.e. land, refuel from an 
air tanker, etc. The AIRPLAN net is also comprised of 

emergency subnets for each aircraft which display a 

procedural check-off list for different types of 
emergencies . 

On a success/failure continuum, AIRPLAN has 
proven to lie toward success for two reasons. 

1. It is an alternative to the slower, manpower 
intensive, manual systems that are used on all other 
aircraft carriers. 

2. AIRPLAN displays can be channeled to the ship's 
secure closed circuit television system, as well as 
the Perqs. This allows monitoring of air operations 
from many compartments aboard ship including all 
squadron ready rooms, the bridge, lower and hanger 
deck control. 

Although AIRPLAN is popular among personnel 
concerned with flight operations it cannot be relied on in 
an emergency, because it suffers from the same hardware and 
software reliability problems that afflict the SORM and 
Weapons elevator programs. 

d. Planning and Evaluation Subnets 

Planning and Evaluation (P and E) subnets 
complete the triad of original 20G applications first 
envisioned for implementation on board U.S.S. CARL VINSON. 
These subnets were intended to support both SPECIFIC PLANS 
(one-time activities), and GENERIC PLANS (iterative 
activities) at the department head level and above. Newell, 
McCracken, Robertson and Akscyn described this on-line 
planning as follows: 
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"Plans will exist in an integrated ZOGnet, which will be 
updated and modified continually as each plan is 
extended and changed. Exploration of plans from 
different perspectives will be possible, e.g. by task, 
by persons or by resources. Some automatic monitoring of 
plans for consistency and critical events, and some 
propagation of status through plans will be possible." 
T Ref . 21] 



Within each of these subnets, two basic types of 
ZOG developed plans can be displayed. These are Specific 
Responsibility Task Nets and Specific Responsibility Time 
Line Nets. The Task Nets show the hierarchical relationship 
of the tasks to be performed, i.e. it breaks them down into 
components and subcomponents, but not in the chronological 
order for completion. It also indicates the person or group 
responsible for accomplishing the task, the required date of 
completion, and the expected amount of time to complete the 
task. The Time Line Nets exhibit time relationships between 
the tasks. These tasks could be sorted by starting date, 
completion date, and over time periods varying between one 
day and eighteen months. By making a selection from the Time 
Line Net, the related task frame of the Task Net along with 
its detailed information will also be displayed. A hardcopy 
of these timeline charts could be printed if desired. The 
format of these plans is generally that of a standard Gantt 
chart . 

With the installation of ZOG on board U.S.S. 
CARL VINSON, many formally structured P and E subnets were 
established for ship's departments and personnel. See table 
I for assigned machines and locations. 

Although these planning and evaluation subnets 
suffered from the same hardware and software problems as did 
the SORM, they appear to have been used much more 
extensively. During the U.S.S. CARL VINSON's 1983 cruise, 
108 subnets were created besides the formal ones enumerated 
above. Of these subnets, 95 can be classified as primarily 
supporting planning. [Ref. 22] 
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TABLE 

Assigned Subnets and 

ASSIGNED TASK SUBNETS 
Air Officer (AOPS 

Aviation intermediate 
Maintenance Department (IMDO 
Management Department (MGTO 
Engineering Department (ENGO 



Medical Department (HMED 

Navigation Department (NAVO 
Operations department (OPSO 
Personnel Department (PERS 
Reactor Department (REAC 

Strike OPS Department (OXOE 
Supply Department ( SUPO 

Senior Chaplain 
Weapons Department (WEPS 

Executive Officer (YYXO 



I 

Machine Locations 



TASK) 


MACHINE LOCATION 
Air Ops office 


TASK) 


AIMD Office 


TASK) 


Conference room 


TASK) 


Engineers logroom 


TASK) 


Medical office 


TASK) 


Ship's bridge 


TASK) 


Ops office 


TASK) 


PERS office 


TASK) 


REAC office 


TASK) 


Strike OPs Office 


TASK) 


Supply office 


TASK) 


Chaplain's office 
Weapons office 


TASK) 


XO 1 s office 



Van Matre, Moy, and McCann attribute this 
proliferation of activity in creating subnets midway through 
the cruise to two factors. 

1. The users had gained two months additional experience 

with ZOG, and were therefore becoming more 

proficient . 

2 . ZOG became easier to use because an update to the 

software "enabled a user to be presented with his own 
unique 1 top frame ' when first logging on, 

instead of the ZOG data base top frame" 
[Ref. 23]. 
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While these two factors undoubtedly contributed to expansion 
of P and E subnets, the cruise itself was probably the 
primary reason for this noted increase. Personnel who 
actually developed and used these subnets were on board the 
ship 24 hours a day with no interruption from land-line 
telephones or ship visitors. This translates into increased 
manhour availability for creating these subnets. The cycle 
of the cruise is also partly responsible for the development 
of these planning nets. When a ship first gets underway for 
a major cruise, its operational tempo is one of training and 
operational commitments. Its near term planning consist 
primarily of fulfilling these commitments. About halfway 
through a cruise, the ship will shift its planning emphasis 
from an almost pure operational mode, to one that will 
prepare it for the myriad of inspections, training 
requirements, maintenance, and other demands that will 
inundate it on its return to the United States. It is a 
combination of all these factors taken together that 
impacted on the proliferation of P and E subnets during 
U.S.S. CARL VINSON's first world cruise. 

One specific task that consistently used one of 
these planning subnets was the development of U.S.S. CARL 
VINSON Greensheets . These are "plans of the day" (daily 
plans) that are universally used on all U.S. Navy ships. 
They list deviations from the daily routine of shipboard 
life, i.e. changes in meal hours, meetings and scheduled 
events along with times and personnel concerned. Onboard 
U.S.S. CARL VINSON, the department heads would give the 
Assistant Operations Strike Officer the information to be 
included in the daily Greensheets. It took him about two 
hours to prepare them after receiving the last input. This 
is about the same time it takes to prepare the plan of the 
day on other Navy ships. The main difference between these 
Greensheets and another ship's plan of the day is that the 
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Greensheets actually included a two day plan to allow for 
better planning, and could be electronically disseminated 
almost immediately to the Perqs. Hardcopy Greensheets still 
had to be run off and delivered newspaper style to the vast 
majority of the crew. 

Another area where planning subnets were used 
frequently was in getting the ship underway. To get a ship 
underway requires a great deal of planning and coordination. 
Tugs must be scheduled, charts corrected, engineering 
equipment tested and brought on-line, food and supplies 
brought on board, etc. Preparations will usually start days 
and sometime weeks before actually taking in the lines and 
getting the ship underway. A ZOG planning and evaluation 
subnet was used on the U.S.S. CARL VINSON to provide an 
online and hardcopy checkoff list to ensure that all 
required tasks were completed at the proper time and in the 
order they were scheduled. By keeping this information 
on-line, an up-to-date date tailored plan could be 
automatically created, and task relevant information 
displayed for either a specific person or billet (specific 
assigned shipboard job). The status of overall underway 
preparations was also available for concerned personnel. 

A third area where this type of subnet proved 
useful was in preparing for the ORSE (Operational Readiness 
System Evaluation) . This is an involved inspection of the 
engineering department on board a nuclear vessel. Both the 
engineer and reactor officers used planning and management 
nets to assimilate and correlate information concerning 
personnel availability, training, checkoff list, schedules, 
etc . 

It appears that planning and evaluation subnets 
were used extensively on board the U.S.S. CARL VINSON 
despite hardware and software problems. One possible reason 
for this is that the only alternative solution was often 
manual mode. 
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E. A CRITIQUE OF TECHNOLOGY TRANSFER 

If the sole objective of the ZOG technology transfer 
concept was to expedite the transition of technology from 
the research laboratory of Carnegie-Mellon to the 

operational environment of the U.S.S. CARL VINSON, then it 
is an unqualified success. Success, however, is a nebulous 
term that varies with time and the perspective from which 
the system is being judged. For the U.S.S. CARL VINSON, it 
hinges more on the future prospects of ZOG and its progeny 
than its past. This is as it should be, because the Perq/ZOG 
system as implemented on board the U.S.S. CARL VINSON has 
been fraught with problems. The reason for this is 

four-fold. 

1. ZOG was originally designed to run on the SPICE 

operating system. Two months prior to the ship's 1983 
cruise this operating system was deemed 

inappropriate and its planned implementation on board 
the U.S.S. CARL VINSON canceled. The standard Perq 
operating system was designated to take its place. 

2. ZOG, when first implemented in an operational 

environment was a first generation system 
undergoing constant development at a rapid pace. In 
July of 1983, version 19.1 was being used on board 

U.S.S. CARL VINSON. By October of 1983, the ship had 

installed version 23.1. Each version represented a 
major improvement over its predecessor, representing 
everything from implementation of an electronic mail 
system to installation of the new personalized ZOG 
frame previously mentioned. 

3. ZOG had been installed too fast. As a direct result 
of the rapidity of ZOG's implementation, many 
problems occurred that could have been minimized or 
prevented. One example of this is in the area of 
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hardware. Both the Perq minicomputers and Ethernet 
system experienced a great deal of problems with 
electronic components as a result of voltage 
fluctuations. These problems were a direct result of 
utilizing ship's power without the benefit of voltage 
protection devices. When surge suppressors (voltage 
line filters) were finally installed three months 
into the cruise, electronic fault problems decreased 
[Ref. 24]. While voltage spikes can increase fail 
time on electronic equipment, a major power surge 
will really wreak havoc on computer electronics. In 
starting a large induction motor for example, a 
tremendous amount of current draw will be 
experienced; a 300 AMP electric motor will initially 
draw approximately 1500 amps of current. On some 
ships, depending on the power source, this can result 
in severe damage to any computer or other electronic 
equipment that is not protected with something more 
than a simple surge protector. 

4. A fourth reason the Perq/ZOG system appeared to have 
so many problems is simply because the users gave the 
system a good workout. If the system had not been 
relentlessly used, then many of these problems could 
have gone unnoticed. 

1 . Disadvantages of ZOG 

ZOG exhibits many disadvantages as it is presently 
installed on board U.S.S. CARL VINSON. These include the 
following: 

a. "ZOG sacrifices efficiency of particular applications 
to get integration" [Ref. 25]. ZOG makes many 
compromises because it is attempting to be all things 
to all types of users. This results in high 
processing time and memory overhead within the 
computer itself. 
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b. "ZOG doesn't support a fast database query language" 
[Ref. 26]. To achieve flexibility and portability of 
the database ZOG data is stored in mass storage as 
text files. This requires a great deal of computer 
overhead when parsing and unparsing ZOG frames. 

c. ZOG is "Biased too much toward a breadth-first view" 
[Ref. 27]. This was discussed in an earlier part of 
this chapter. 

d. "ZOG cannot be used over standard telecommunication 
lines." [Ref. 28] A 1200 baud transmission rate is 
too slow for using ZOG. It should be more than 9600 
baud to obtain the full benefit of this type of 
database . 

e. ZOG experiences decreasing speed as the database 
grows. The U.S.S. CARL VINSON experienced a response 
time of .5 seconds when accessing data that was 
resident on the machine being used. If the data had 
to be brought in from a part of the database resident 
on another machine, then access time was increased to 
1.5 seconds when both machines were running normally. 
[Ref. 29] The original design goal for ZOG was near 
.25 seconds, and was regularly reached in the 
laboratory. As database use and size increase, speed 
can expect to decrease even more. 

2 . Advantages of ZOG 

Strictly from a user's viewpoint, a ZOG type system 
has several advantages over a more conventional mainframe 
architecture, or even a network of mini/microcomputers that 
use non-database type software. Some of these advantages are 
as follows: 

a. Redundancy of hardware. Those who have experienced 
shipboard life quickly realize that equipment wears 
faster, breaks quicker, and has a shorter life span 
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than equivalent equipment that is used in a less 
hostile environment. This is especially true of 
computer equipment. It must be designed to contend 
with high humidity, temperature variances, salt air 
corrosion, power fluctuations, and structural 
movement of the ship itself. Even then, all other 
things being equal, shipboard installed equipment 
will still have a shorter life expectancy and greater 
failure rate than equivalent equipment ashore. A 
redundant hardware architecture, such as the Perq 
system, means that the entire system will not come to 
a crashing halt as a result of the loss of one, two 
or even more computers. 

b. Redundancy of data. This principle carries over into 
the software area as well. By using a distributed 
database the loss of one or more nodes does not bring 
the whole system to a screeching halt. 

c. Ease of use. This is especially important in a 
shipboard environment where high rates of personnel 
turnover often occur. A computer novice can be taught 
to navigate through ZOG in less than thirty minutes. 
In two hours he can be taught to add new material to 
the database with ZED. [Ref. 30] 

d. Browsing capability. Closely tied to ease of use is 
browsing capability. Instead of having to search the 
database using query methods, the new user can jump 
right in and start exploring the database through 
random browsing. This capability in effect functions 
as a tutor allowing the new user to explore the 
database and familiarize himself with how it is set 
up. The ZOG system defaults to the browsing mode when 
it is entered. 

e. Large database. A fifth advantage of ZOG is that it 
supports a large database, e . g . the U.S.S. CARL VINSON 
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had over 30,000 frames. Theoretically, the only limit 
on size is mass memory of the hardware device, and 
possibly some operating system constraints. 

f. Allows more information to be produced from a given 
amount of data. In effect, a database allows a piece 
of data to be entered once and used by everyone, 
instead of everyone entering that same piece of data 
in a personalized file. Thus, one piece of data is 
supplying more information to more people. This is 
especially important on board ship. For example, if a 
supply officer were to keep his complete requisition 
status (status of items on order) in a database, the 
engineer, operations officer, or other interested 
personnel could obtain the latest information simply 
by addressing the database. This would free up the 
supply officer and his men for more constructive 
tasks, as well as keeping appropriate personnel 
apprised of their requisition status. The checkoff 
sheet for getting the ship underway is a working 
example of this concept. Assignment of task and 
times which will result in the completion of required 
activities needed to get the ship underway are loaded 
into the ZOG database. This information is then used 
by anyone on the ship with access to a Perq who has 
need of this data. 

g. Elimination of data duplication. By using a database 
system, many artificial partitions used to separate 
data in a conventional file system are eliminated. 
This allows a specific piece of data to be entered 
once, yet used over and over by many different 
programs. Consequently, the number of times that a 
specific piece of data is entered into the database 
is reduced, while at the same time the amount of 
information that can be derived from that particular 
piece of data is increased. 
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Additional advantages derived from ZOG's distributed 
database include data integrity, data independence from 
embedded programs or agents, and the capability for better 
data management. 

F. CONCLUSIONS 

ZOG appears to be much more flexible in areas which can 
use the system primarily as an interface for embedded 
programs or other technology such as AIRPLAN and the weapons 
elevator technical manual. It is inflexible in areas where 
it must function as an organizing element, i.e. used as the 
primary tool for creating and arranging difficult structural 
documentation, such as the SORM. While it can be made to 
support planning and evaluation subnets, much of this 
support is really done with the brute force method. Most of 
the planning functions could be done more efficiently by use 
of a standard turnkey system with an electronic mail 
capability. Technology transfer does offer more reliability 
than the other systems presently on U.S.S. CARL VINSON 
primarily because of its distribution features. It is less 
prone to total failure due to fire, water or other 
catastrophe than is a centralized system. 

With the influx of new personnel, ZOG usage will 
probably go down. This is because many of the new people, 
while just as dedicated as the older personnel, will not 
have benefited by such a close association with the 
developers as did the original personnel. They will also 
have more systems to chose from. 

While this will probably mean that ZOG is used on a less 
frequent basis, it should not be abandon. Instead, it should 
be utilized in those areas in which it has proved the most 
feasible . 
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III. WANG 



A. INTRODUCTION 

Some of the more common computing equipment found on 
board Naval ships and installations in recent years has been 
manufactured by WANG Laboratories Inc. (WANG). This 
phenomenon is a direct result of WANG's strategy of 
marketing its products as "word processers" vice "data 
processers", as most other vendors have done. While an 
off-the-shelf WANG word-processing machine is configured 
primarily to perform word processing functions, it can be 
turned into a powerful data processor with just a few minor 
adjustments and the installation of the appropriate 
software. Nevertheless, up until 1982, WANG word-processing 
products had been listed and procured under the GSA (General 
Services Administration) contract schedule as office 
equipment (federal supply class 74) instead of under the 
more restrictive GSA contract schedule for automatic data 
processing equipment (federal supply class 70). In 1982 the 
Navy issued an instruction defining automatic data 
processors and equipment by purpose instead of by class 
[Ref. 31]. With the issuance of this instruction Navy 
commands could no longer purchase a WANG word processor and 
convert it into a data processing machine without having to 
go through the extensive and complicated acquisition 
procedures required for procuring automated data processing 
equipment . 

While the majority of WANG processers on board naval 
vessels are used strictly for word processing, there are six 
noted exceptions. Five of these exceptions are the WANG 
VS-80 prototype SNAP II systems installed on board the 
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U.S.S. David R. Ray, U.S.S. Kidd, U.S.S. Scott, U.S.S. 
Chandler, and the U.S.S. Callaghan. The U.S.S. Fife and the 
U.S.S. New Jersey were originally outfitted with these WANG 
VS-80 prototypes as well, but have since had them replaced 
with the Harris SNAP II system. The WANG systems originally 
installed on the U.S.S. Fife and the U.S.S. David R. Ray 
were implemented as SNAP II prototypes by the Commander 
Naval Ships Engineering System Command ( COMNAVSEASYSCOM ) , 
while those installed on the remaining five ships were 
procured, implemented and designated as interim SNAP II 
systems by Commander Naval Surface Forces Pacific 
(COMNAVSURFPAC). This was done before the selection of the 
Navy's standard SNAP II computer system to get non-tactical 
automation capability on board each of these newly 
commissioned ships. Software was jointly developed and 
implemented by NAVSEA (PMS-389) and Navy Management Systems 
Support Office (NAVMASSO) Norfolk. In July 1983 NAVMASSO 
placed a moratorium on further software development for the 
WANG VS-80 system. This was followed in August 1983 by 
COMNAVSURFPAC making known his intentions to replace the 
WANG prototype system with the standard Harris SNAP II as 
they become available. [Ref. 32] 

The other installation which uses a WANG system for more 
than simple word processing is on board the U.S.S. CARL 
VINSON. It is this system that will be the focus of this 
chapter . 

B. WANG AND THE U.S.S. CARL VINSON 

In June 1980, a WANG System-20 computer was leased and 
installed in a naval office building being used by the 
precommissioning crew of the Navy's aircraft carrier, U.S.S. 
Carl Vinson, then under construction at the Newport News 
Shipbuilding and Drydock Company in Newport News, Virginia. 
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It consisted of a single terminal, a floppy disk drive, and 
one printer. The system-20 ran what is called "Glossary 
Language" besides standard COBAL. 

Glossary language is a key word oriented language that 
can be used for calling a library of routines, utilities, or 
series of keystrokes. It is an integral part of the word 
processing package available on the System-20. While using 
this language is analogous to programming a PF key on an IBM 
System, it will do much more. For example, the glossary 
function can be programmed to format standard documentation 
such as a form-letter. When activated, it will print 
required information like a letter head, place in an 
‘automatic return and jump down to the address area. The user 
will input the name and address of the intended recipient 
and hit the return key. At that time the glossary language 
will print out the remainder of the letter. 

The primary purpose for obtaining the System-20 was to 
enumerate and track the thousands of tasks requiring 
completion before the ship could be commissioned. This 
planning and control function was to be the precursor of the 
planning and evaluation subnets that would later be 
developed and used on the Perq/ZOG system. 

Once installed, the System-20 proved to be extremely 
useful. As a result. Captain Richard Martin, the 
prospective commanding officer of the U.S.S. CARL VINSON, 
decided to expand its users to include the ship's department 
heads. By March, it had become apparent that the system was 
too small to perform all the functions and tasks now 
required of it. Consequently, in April 1980 the System-20 
was traded in for a System-30 that was also leased from 
WANG. The System-30 was configured with 10 terminals, 3 
printers, and a 30-MB (megabyte) hard disk drive. 

Shortly after the WANG System-30 was installed, it 
became apparent that computing demands for both the 
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precommissioning planning and control requirements and the 
department heads had been greatly underestimated. With the 
inclusion of department heads in the coterie of WANG users, 
the proverbial door had been opened for personnel within the 
various departments themselves to access the system. Once 
this occurred, contagion for the WANG System-30 began to run 
rampant throughout the ship. Personnel from the 
administrative, medical, engineering, personnel and other 
departments began to find new and innovative ways to use the 
WANG to make their own work more efficient and effective. As 
a direct result, a WANG VS-80 system was leased in July 1980 
to upgrade the System-30. The System-30 was retained on 
board the ship for use by the engineering department until 
September 1983, when its lease ran out and it was returned 
to WANG. The VS-80 leased from WANG increased the size of 
the hard disk drive from 30-mb to 90-mb of storage. To 
ensure that enough memory was available, an additional 75-mb 
was procured and added to the VS- 80 specifically to upgrade 
the planning and control functions. 

Although the VS-80 system with additional memory was 
adequate for the needs of the U.S.S CARL VINSON's 
precommissioning crew, it again proved too small once the 
ship was commissioned and became an operating unit of the 
U.S. Navy. Captain Martin then decided the ship should 
obtain the largest processor system made by WANG, a super 
mini computer called the VS-100. This would meet the ship's 
present needs while allowing for future expansion. In July 
1981, the VS-80 system was returned to WANG in exchange for 
a leased VS-100 system. The VS-100 was configured with a 
spider network of 28 smart terminals directly wired into the 
mainframe, two 288-mb disk drives, one magnetic tape drive, 
one telecommunications channel, and a 2-mb main memory. By 
October 1984, the WANG VS-100 System was purchased outright 
by the ship and upgraded to include 86 terminals, 21 
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printers, 4 disk drives, 11 telecommunications channels, 
8-MB of main memory, and a prototype WANG Net. 

C. A SECOND WANG VS -80 SYSTEM 

In January of 1982 the management department of the 
U.S.S. CARL VINSON obtained a second WANG VS-80 System, 
which had originally been procured by the U.S.S. Lexington 
(AVT-16). While on board the U.S.S. Lexington, the 110 Volt 
Alternating Current (VAC) VS-80 System had inadvertently 
been connected to a 220 VAC power source, which resulted in 
damage to a majority of the internal electrical and 
electronic components. Once in the possession of the U.S.S. 
CARL VINSON's management department, repair parts were 
procured from WANG. Within six months, technicians on board 
the U.S.S. CARL VINSON had made the system fully 
operational . 

This particular system was installed in the ship's 
Combat Information Center (CIC) . It is configured with one 
288-MB disk drive, a printer, and five smart terminals 
connected to the CPU in a spider network. Neither the VS-80 
System nor any of its five workstations have external 
communication capabilities outside the tempest certified 
space. The system is being used to handle highly classified 
intelligence information. 

D . WANG NET 

In 1983, the U.S.S. CARL VINSON was selected as a 
beta-test site for a prototype WANG Net. The WANG Net 
implemented on the ship actually consisted of two separate 
nets (one upper, one lower) of the dual cable, broadband, 
active headend type design. This means the equipment uses 
two cables to connect into the main trunk line. One cable is 
used for transmission and one cable is used for reception. 
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thus eliminating the need for two different frequencies. The 
upper net serves all terminals located above the hanger 
deck, while the lower net serves all terminals located below 
the hanger deck. It is this lower loop that presented an 
interesting engineering problem that required three 
iterations of installation before the net became fully 
operational . 

The main deck on board a ship is called the "damage 
control deck" . All compartments located below the damage 
control deck must maintain watertight integrity, which means 
that no new penetrations or openings can be made in 
bulkheads (walls), overheads (ceilings), or decks (floors). 
Provisions are made during the construction of a naval ship 
to provide a path for cables and wires to pass through these 
inviolate partitions. These paths are then sealed with a 
pliant material to maintain the compartment's watertight 
integrity. This close grouping of different types of cables 
can present problems. High voltage lines, telephone wires, 
and computer cables are all joined together and run through 
compartments and partitions as a single group in what is 
called a cablerun. These cableruns are often routed near 
light fixtures, generators, and other sources of 
electromagnetic interference. It was these cableruns which 
proved troublesome in the initial attempt to install the 
WANG Net. The first attempt to implement the system used 
unshielded RG-11 coaxial cable which simply did not work. 
CATV-type amplifiers installed at intervals along the net 
were also insufficient to keep signal attenuation less than 
40 DB . As a result, a second attempt was made using single 
shielded RG-11 cable and a special amplifier designed to 
keep signal loss to less than 40 DB . While this mitigated 
the problem somewhat, it still required a third attempt 
before the system was fully operational. On this last 
attempt RG-11 double shielded cable was installed along with 



41 



some minor adjustments to the special amplifiers, before the 
system became operational. 

The current configuration of the WANG Net uses a 
branching- tree topology to connect the processing equipment 
to the two single trunk lines that run throughout the ship. 
Several amplifiers and netmuxs (network multiplexers) are 
attached to the network cable at different points. A netmux 
is simply a device which permits the simultaneous 
transmission of many independent channels into a single 
high-speed data stream by dividing the signal from different 
device channels ( terminals ) into successive alternate bits. 
In a nutshell, a netmux can be compared to a black-box that 
takes input data supplied by anywhere from 1 to 8 terminals 
and outputs it to the main trunk line of the WANG Net, or 
vice versa. By using a network system such as this, 
terminals and personal computers can be easily attached to 
the mainframe without the necessity of stringing a new cable 
each time. This results in smaller cableruns and better 
watertight integrity between adjoining compartments, because 
fewer cables penetrate common watertight bulkheads. It also 
permits the WANG VS- 100 system to run more than the 96 
workstations it would have been limited to had it operated 
with only the spider configuration. For each netmux 
installed in the WANG Net an additional 8 workstations can 
be added to the system. While there is no limit to the 
number of netmuxs that can be installed, the present 
operating system (VS-OS, revision 6.2) on the WANG VS-100 
restricts the system to a total of 128 terminal nodes. 

E. ESSENCE OF WANG 

Except for the WANG Net, the Wang VS-100 system as 
presently configured on board the U.S.S. CARL VINSON is the 
same system being used in numerous commercial and industrial 
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applications. The essence of this -system is its ability to 
perform diverse tasks of both a general and specific nature. 
It can be used to perform data processing, word processing, 
and electronic mail, yet still be adapted to specialized 
use. An example of this specialized use on board the U.S.S. 
CARL VINSON is the WANG's backup function as the ship's 
message processing distribution system (MPDS). The MPDS is 
a system unique to Nimitz class aircraft carriers and 
communication, command, and control ships (LCC's). It is a 
system that takes a message received in the ship's 
communication center, reads the standard subject 
identification code embedded in the header of each message, 
and routes it to the action officer or department that has 
cognizance over that particular subject area. For example, 
if the subject concerns fuel for the ship's emergency diesel 
generation system, the engineering department would 
automatically be routed a copy as the message arrives on the 
ship. What distinguishes this system from similar procedures 
on other ships is that MPDS is done electronically without 
human intervention. MPDS actually consist of a small 
processor in the communications center that is linked to 
several hardcopy terminals dispersed to various functional 
areas throughout the ship, i.e. engineering, supply, 
operations, etc. Although MPDS fully automates the 
communications center on board the U.S.S. CARL VINSON, a 
separate paper tape punch creates a record tape of each 
message transaction. If the MPDS were to fail, the 
information on these paper tapes could be uploaded to the 
WANG VS- 100 with an attached paper tape punch and 
distributed to the appropriate departments and personnel 
through the WANG terminals. Messages can also be composed on 
the WANG VS-100 and output on a paper tape. This paper tape 
can then be taken to the ship's communication center and 
transmitted with regular teletype communications equipment. 
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The WANG VS- 100 is, therefore, a complete backup system to 
MPDS. 



1. The User and the WANG VS-100 

A majority of present and former personnel of the 

U.S.S. CARL VINSON interviewed about the ship's WANG 

installation consider the VS-100 to be user friendly. This 
particular system is completely menu driven and appears to 
be easy to use. One reason for this is because it is a 
commercial system that was designed to be used by a 
multitude of different users. A shipboard technician summed 

it up when he said "if you can read, you can use the 

system" . 

2. Evaluation of WANG on board the U.S.S. CARL VINSON 

The WANG VS-100 capabilities that are used the most 
on board the U.S.S. CARL VINSON are the word-processing 
package and the electronic mail feature. One member of the 
ship°s management department estimated that 90% of all jobs 
performed on the WANG VS-100 involve interactive 

word-processing, while only 10% involve data processing. 
This is in consonance with one of the two original reasons 
for procuring the VS-100 in the first place, i.e. to provide 
the ship with a powerful, versatile word processing 
capability. The other reason, which was discussed briefly in 
an earlier part of this chapter, was to aid in the area of 
planning and control. 

Although the WANG VS-100 is a centralized unit, it 
has proven much more reliable than the Perq distributed 
System discussed in Chapter Three. There are four primary 
reasons for this phenomenon: 

a. The WANG VS-100 is a rugged machine. It is designed 
to operate between 196 vac (volts alternating 
current) and 253 vac without sustaining electronic 
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damage. Additionally, a dedicated w/30a circuit 

breaker is installed with all WANG VS-100 

installations to shut the system down in case of 
electrical overload. [Ref. 33] 

b. Members of the management department ensured that an 

isolation transformer was properly installed on the 
ship's power outlets that supplied the WANG VS-100. 
Although the rational for an isolation transformer on 
board ship is really for electrical safety and 
electrical ground isolation, it has an added 

capability of attenuateing electrical noise in 
electronic equipment. In addition, the ship's force 
installed a low voltage protection device to shut 
down the system if voltage dropped too low. This 
prevents the system from voltage surge if power is 
suddenly restored after a loss of the electrical 
load . 

c. A third reason the WANG VS-100 proved so much more 

reliable than the Perq System is because it is 
enclosed within its own air conditioned space. While 
most of the Perq's were also located in air 

conditioned spaces, their spaces were more likely to 
be kept at a temperature and humidity conducive to 
human comfort than that for optimum machine 

performance . 

d. The final reason the WAN G fared so much better than 
the Perqs was because the WANG mainframe was located 
in a limited access area where it was constantly 
monitored by trained technical personnel. If an 
abnormal situation began to develop, it could be 
quickly detected and appropriate corrective action 
taken. With the Perq System, the computers were 
distributed throughout the ship where abnormalities 
were more likely to occur and less likely to be 
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detected by qualified technical personnel. This 
situation ultimately resulted in more equipment 
casualties to the Perqs. 

Before October 1984, the ship had experienced only 
one significant problem with the WANG VS-100. A clock 
circuit had failed, which in turn caused a cache memory 
problem. Ship's technicians corrected this problem within 
two hours of its occurrence. The Perq computers on the other 
hand had suffered numerous equipment problems throughout 
this same time period. 

a. Electronic Mail and Word Processing 

The combination of electronic mail and word 
processing on the WANG VS-100 have served to reduce the 
ship's administrative work-load considerably. One particular 
area in which this is evident is in the preparation of 
personnel evaluations. Onboard most Navy ships, a chief 
petty officer would make the first handwritten draft of an 
enlisted person's evaluation. He would then submit it to his 
division officer who would either send it back to the chief 
for revision, or submit it to his department head. The 
department head would then review the evaluation and either 
send it back to the division officer for further revision or 
submit it to the executive officer for final review and 
signature approval. At any point in this process, changes 
can be made before it is submitted to the next person in the 
chain of command, or it can be sent back down the chain for 
partial or total revision. It is not unheard of for an 
evaluation to traverse through this procedure two or three 
times before it is finally approved and signed. After one 
iteration of this traversal the evaluation oftentimes must 
be completely rewritten or retyped. Officer's fitness 
reports follow a similar procedure except they are initiated 
by the next senior officer in the chain of command and 
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signed by the commanding officer. Some personnel are 
required to have evaluations submitted on them every six 
months, while everyone receives at least one a year and two 
if they are being transferred off the ship. Multiply this 
simple evaluation process to include the thousands of 
personnel that make up the crew of the U.S.S. CARL VINSON 
and the task quickly becomes non-trivial. Envision this 
task being performed on paper and it becomes overwhelming. 
With the WANG VS-100 this same evaluation process is greatly 
simplified. The chief petty officer can type in the twenty 
or thirty evaluations he is required to initiate into the 
WANG System and send them electronically to his division 
officer. The division officer will add his comments to those 
evaluations he feels are correct and forward them 
electronically to his department head. Those that he rejects 
are returned electronically to the same chief petty officer 
who initiated them for revision and resubmission. This same 
process is performed between the department head and the 
executive officer, and between the executive officer and the 
commanding officer for officer fitness reports. Once the 
evaluation has received final approval from either the 
Commanding Officer or the Executive Officer, the WANG will 
perform a final spelling check, automatically format, and 
print a hard copy. 

Although this example concerns only the 
shipboard evaluation process, the method of electronically 
creating and routing all sorts of correspondence and reports 
is used extensively on board the U.S.S. CARL VINSON. One 
particular area where it is used on a daily basis is in the 
creation and release of Naval messages. The drafter will 
initially create a Naval message using the word processing 
capabilities of the WANG VS-100. These capabilities include 
a spelling checker, standard fill in the blank type formats 
for the most commonly sent messages, and a plain language 
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address (PLAD) look-up program besides other standard word 
processing features. The VS-100 will look up the correct 
PLAD and insert it in the header of the message. Once this 
is done, the message will be routed to the commanding 
officer for his review and release. The Commanding Officer 
can then review and release the message from the bridge, his 
cabin, or any place on the ship where a WANG terminal is 
located. This precludes his having to carry around a stack 
of paper when dealing with routine messages, or having to be 
chased down to get a release signature in the case of more 
urgent ones, thereby saving uncountable numbers of manhours. 
Once these messages are released by the Commanding Officer, 
they are printed out on a paper tape and taken to the ship s 
communication center for transmission. The combination of 
electronic mail and word-processing has proven highly 
successful on board the U.S.S. CARL VINSON. 

. b. Data Processing 

The VS-100' s data processing capabilities are 
not being fully used on board the U.S.S. CARL VINSON. One 
reason for this is because other non-tactical automated 
systems are performing the majority of the ship's required 
data processing tasks. As of October 1984, a Durango 
Computer was being used for maintaining records and creating 
reports in the food service management area, while the 
Honeywell Snap I System was being used as an interface 
between maintenance and supply functions, ordering parts, 
printing paychecks, etc. This leaves very little data 
processing actually being performed on the WANG VS-100. 
There are some exceptions, however. One particular area on 
board the ship in which the WANG's data processing 
capabilities are being used is to create customized reports 
of ship's personnel who are eligible to vote in different 
states and elections. For example. If the voting officer 



48 



needs to know how many members of the ship's engineering 
department are eligible to vote in a special election in 
Michigan, he can process this data on the WANG and create a 
customized report enumerating this information. The voting 
officer can then disseminate the needed information to the 
appropriate personnel. 

The career counselor is another person who uses 
the data processing capabilities of the WANG VS- 100. He is 
responsible for maintaining a current list of regulations 
and guidelines concerning reenlistment incentives. Navy 
schools, and general career path information. The career 
counselor will also maintain a master schedule of career 
interviews, which can be disseminated to division officers 
on a monthly or weekly basis. This is simply a list of 
ship's personnel who are scheduled for division officer 
reenlistment interviews. With the WANG VS-100, he is able to 
maintain his data, process it, and create required reports 
and interview schedules quickly and easy. For example, if 
entrance requirements for a specific Navy school are 
lowered, the career counselor can quickly produce a list of 
ship's personnel who had previously expressed an interest in 
that school, but until now had not met the entrance 
requirements. He can then contact the individuals concerned 
and ascertain if they are still interested in attending the 
school . 

The ship's Damage Control Assistant (DCA) 
officer also uses the data processing capabilities of the 
WANG VS-100 to maintain the ship's master compartment check 
off list (CCOL) . Each compartment on the ship has a CCOL 
posted in a conspicuous location near its access, which 
lists and describes all fittings and systems within that 
particular compartment. The CCOL also gives the damage 
control classification, which tells when the fittings or 
systems should be activated or secured, and indicates the 
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ship's division that is responsible for their maintenance 
and closure status. If a division needs to have a complete 
list of all the deck drains it is responsible for 
maintaining, the DCA can produce such a list from the master 
using the data processing capabilities of the WANG. Using 
the WANG's database, the DCA can also produce a customized 
report of compartment material and equipment deficiencies 
for each of the last four zone inspections. Zones are 
nothing more than artificial divisions or groupings of 
equipments and compartments to facilitate their inspection, 
hence the term zone inspection. 

Other areas that use the WANG VS-100 for data 
processing include the medical and dental departments. The 
medical department uses the system to identify personnel who 
are due for shots and to monitor urinalysis testing for 
drugs, while the dental department identifies personnel 
requiring dental exams. While there is some data processing 
being performed on the WANG VS-100, it is not enough to 
justify the systems existence on that basis alone. Current 
justification relies on the areas of word- processing and 
electronic mail. It has been these two areas that have been 
the driving force for increasing both the efficiency and 
effectiveness of numerous administrative functions on board 
the U.S.S. CARL VINSON. 

c. Specific Applications 

With the implementation of the WANG VS-100 on 
board the U.S.S. CARL VINSON, an abundance of computing 
power was suddenly made available to ship's personnel. 
While most of the applications run on the WANG by these 
shipboard users is of a general nature, many of them proved 
to be quite innovative. One of the more novel uses of the 
WANG VS-100 was developed by the ship's first Commanding 
Officer, Captain Richard Martin, but is actually employed 
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by the ship's embarked airwings. An airwing is a separate 
organizational entity that is temporarily assigned to the 
ship for an operational deployment or exercise. The airwing 
is made up of different squadrons, which consist of the 
pilots and support personnel required to operate and 
maintain a group of like aircraft. These support personnel 
include mechanics, plane-crews, and administrative 
personnel. When an airwing is assigned to the ship for an 
extended amount of time, it will move all its aircraft, 
personnel, and records on board the ship. These records are 
quite comprehensive. They include everything from the 
complete maintenance history of each aircraft to the medical 
and dental records of the airwing's assigned personnel. 
When assigned to the U.S.S. CARL VINSON, these records are 
carried on board electronically filed in the airwings 
portable WANG Professional Computer (PC), which they carry 
with them. Each of these portable computers is configured 
with two duel 5 1/4 inch floppy disk drives, a 10 megabyte 
hard disk drive, 640-KB of random access memory, its own 
operating system, and a serial printer. Once on board, the 
WANG PCs are connected to the VS-100, and all its data is 
uploaded to the mainframe. While attached to the U.S.S. CARL 
VINSON, the airwing uses the capabilities of the WANG VS-100 
to maintain files and meet its data processing requirements. 
When the airwing is ready to depart, it downloads its data 
to the WANG PC, and returns to its home base with the PC and 
all it's files electronically recorded. This innovative use 
of the ship's Vs-100 and a WANG PC has permitted the 
different airwings to automate their own administrative 
functions and quickly integrate them into those of the ship 
when embarking. 

Another application that has proven highly 
successful on the WANG VS-100 is the ship's personnel 
information system. This is an on-line database. unique to 
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the U.S.S. CARL VINSON, that contains medical, dental, and 
personnel records for both ship's officers and enlisted 
crewmembers, as well as, other appropriate administrative 
records. To ensure that only properly authorized personnel 
can view information within this database, a Federated 
Management System (FMS) interfaces with the computers 
security program. The FMS assigns all users a special code. 
This FMS code identifies the files and protection classes 
(unprotected, execute-only, read-only or private file) that 
can be accessed by that particular user. When a user first 
logs on the WANG VS-100, he will enter his "user id" and 
"personal password". From this information the FMS will 
internally locate his FMS code and display a menu of data 
files that he is allowed to access. Within the Personnel 
Management System for example, only personnel authorized by 
the medical department along with those having "system 
administrative rights" are allowed to read medical records. 
All members within the WANG division of the management 
department have these "system administrative rights". 

This system allows the personnel officer to 
maintain a mini electronic personnel record for each member 
of the ship's crew. In addition, the career counselor and 
voting officer can use this database to create customized 
reports as previously discussed, while the ship's division 
officers can use it as an on-line division officers 
notebook. A division officers notebook is nothing more than 
a record kept on each man within a division. It usually 
includes his name, present rate, educational level. Navy 
schools attended, noted achievements, etc. 

Additional application areas of a specified 
nature performed on the WANG VS-100 include a messmen 
information system to keep track of messcooks assigned to 
the ship's messdecks, a management department utilities and 
muster list, the public affairs officer's datafiles, the 
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photographic departments equipment list and job order 
information, and a list of navigational aids used by the 
ship's navigator. 

d. Unused Capabilities 

Although the ship uses the VS-100's word 
processing and electronic mail applications extensively and 
its data-processing capacity to a limited degree, it is not 
taking full advantage of the WANG-Net itself. As previously 
discussed, the WANG-Net is of the dual cable active header 
type. Being a broadband network it is capable of multiple 
service analog transmission, i.e. it is capable of 
transmitting data, voice, video, etc. vice strictly serial 
digital signaling as in baseband nets. 

This capability allows the WANG-Net to be used 
in the following four ways: 

1. It can be used to support either WANG PC's or 
intelligent terminals as VS work stations. This is 
the mode in which it is presently being used on board 
the U.S.S. CARL VINSON. These workstations just 
input data to the VS-100 and output it to a CRT 
terminal . 

2. The WANG-Net has a remote telecommunications 
interconnect band that allows it to function as a 
telephone line between different nodes on the net. 
Any protocol may be used as long as the WANG or 
non-WANG terminal devices using this band have 
industrial standard electrical interfaces, and the 
protocols operate at the same speed. 

3. A special WANG PC band is also included which 
connects all stand-alone type WANG PC's into a 
distributed network. The WANG VS-100 cannot be part 
of this system, hence the distributed network will 
still function if there is a casualty to the VS-100 
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itself. This special band uses time division 
multiplexing and operates at 2.5 million bits/second. 
[Ref. 34] 

4. The interconnect band allows Stand-alone PC's to talk 
to each other at either 64,000 bits/sec, 9,600 
bits/sec, 4800 bits/sec, 2400 bits/sec or 1200 
bits/sec. This particular band can also be accessed 
by small computers made by other vendors. [Ref. 35] 
To use these capabilities more fully would 
require replacement of all intelligent terminals presently 
on the net with either WANG PC's equipped with appropriate 
expansion cards, or other vendor equivalents with 

appropriate protocols. 

F. A CRITIQUE OF THE WANG VS- 100 ONBOARD THE U.S.S. CARL 

VINSON 

Being a commercial system designed to accommodate a wide 
spectrum of users, the WANG VS-100 installation suffers from 
the same faults common to most systems attempting to be 
everything to everyone. That is, it does a good job in all 
its shipboard applications and a superior job in a few. 
However, it may not be the best suited system for all the 
applications presently being performed on board the ship. To 
make a reasonable determination as to whether it is the best 
suited system would require a thorough cost/benefit 
analysis, which goes beyond the scope of this paper. To get 
a better feel for the direction such an analysis would take 
some advantages, disadvantages, and management issues will 
be considered below. 

1. Advantages of the WANG VS-100 Installation 

The WANG VS-100 System on board the U.S.S. CARL 
VINSON exhibits many advantages. 
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a. Versatile word processor. The word processor that is 
installed on the ship's WANG VS-100 offers the user 
several diverse capabilities. These include a choice 
of fonts, a documentation shrinker, and even the 
capability to print upside down if required. 

b. User friendly. The management department on board the 
U.S.S. CARL VINSON holds a full three-day training 
session for new users once a month besides special 
classes in basic and cobol programming when the ship 
is on an extended deployment. The monthly training 
session itself consists of an indoctrination to 
computers along with specific tutorial exercises for 
the WANG VS-100 and the word processing editor. It 
has been the experience of some members of the 
management department that a student can perform 
basic applications on the VS-100 terminals after only 
an hours instruction. The reason for this is because 
the system is totally menu driven and therefore, 
extremely easy to learn to use. The system also 
employees a library of standard routines and utility 
programs which make code generation a simple task for 
the more sophisticated user. 

c. Good response time. The WANG VS-100 is designed to be 

an extremely fast machine. In addition to its 
separate cache memory, the VS-100 uses a 64-bit data 
bus between the main memory and other major processor 
components, and a 32-bit central processor (CP) data 
bus. The combination of these three factors results 
in a rapid CPU cycle time (160 

nanoseconds/micro-instruction) . With up to 70 users 
on the system there is virtually no noticeable change 
in response time to the user. Of course, because the 
majority of applications being run on the processor 
concern word- processing vice data processing means 



55 



that the CPU is idle quite a bit of the time. Thus, 
the system usually runs near its fastest speed. 

d. Equipment reliability. From the time the WANG VS-100 
was installed on board the U.S.S. CARL VINSON in July 
1981 until the end of the ship's first cruise in the 
fall of 1983, there was only one major equipment 
failure despite the fact that most of the equipment 
servicing was done on board by ship's technicians. 
Since the end of that first cruise there have been no 
significant equipment casualties reported for the 
ship's WANG VS-100. 

e. Diverse selection of software readily available. 
Being a commercial system, the VS-100 can support a 
wide range of off- the-shelf software along with 
several multiple high-level languages, including ANSI 
COBOL, BASIC, FORTRAN, PL/1, and RPG II. In addition, 
it supports a macro assembler that uses an 
instruction set compatible with that used on an IBM 
360, and an English-like command language called 
"PROCEDURE", which allows the user to create special 
text files that will perform many of the operations 
normally executed interactivi ly . It is similar to job 
control language. [Ref. 36] 

2. Disadvantages of the U.S.S. CARL VINSON' s WANG 
Installation 

The WANG VS-100 System exhibits many disadvantages 
as it is presently installed on board the U.S.S. CARL 
VINSON. These include the following: 

a. Lack of redundancy. Being a centralized system with a 
single CPU, there is no backup if a major casualty 
were to occur to the equipment. This could be 
mitigated somewhat by replacing all the intelligent 
terminals on the WANG Net with self contained 
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personal computers configured with appropriate 
expansion cards to activate the distributed 

processing capacity of the WANG-Net as discussed 
above . 

b. Requires a constant attendant 24 hours per day. 

Unlike the Perqs and the Snap II computers being 
implemented on smaller ships, the WANG VS- 100 

requires an operator to be on duty within the space 
at all times. This attendant is required for security 
as well as for equipment operation and monitoring. 

c. Limited growth potential. The present system 
architecture is set, limiting flexibility for future 
growth to 128 terminals. While the present system 
cannot be expanded beyond these 128 terminal nodes, 
replacement of all intelligent terminals on the 
WANG-Net with stand-alone PC's configured with the 
appropriate expansion boards would increase the 
amount ' of processing that could be done with the 
present configuration. This would postpone if not 
preclude having to go to a larger machine as new uses 
for the VS-100 are developed. 

d. Lack of an uninterruptible power supply (UPS). 

e. Onboard a Naval vessel it is considered good 

engineering practice to rotate ship's service turbo 
generators (SSTG's) on a daily basis to ensure that 
all mechanical systems wear at approximately the same 
rate, as well as, to detect abnormal operating 
conditions in any of the equipment. While this 
shifting of generators is usually carried out in a 
smooth, orderly procedure, it is not uncommon to lose 
electrical power in all or parts of the ship. When 
this occurs, all electronic equipment that does not 
have an UPS must be secured to prevent internal 

damage. The WANG VS-100 does not have a UPS which 
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means that it will shut down in case of a power 
interruption. This results in the loss of any data 
then being input on the intelligent terminals, 
unscheduled down-time, and a time consuming procedure 
to reset the system and bring it back on-line. 

f. Lost data if CPU shuts down. If the CPU should be 
inadvertently shut down through a power loss or some 
other mishap it loses the addresses of the terminals 
that are inputing data at that time. This means that 
all the data in the buffers of the intelligent 
terminals cannot be recovered. 

g. Reliance on one vendor. The WANG VS-100 system and 
associated WANG Net as* implemented on the U.S.S. CARL 
VINSON is a 100% WANG system. Since many commercial 
devices and peripheral equipments are not compatible 
with the VS-100, they must be purchased from WANG 
vice competitive bidding. Hence, the ship is locked 
into using WANG equipment with very few exceptions. 

h. Lack of Navy parts support for the VS-100. Since the 
WANG VS-100 is not a standard system throughout the 
Navy, it is not supported by the Naval supply system. 
This means that the ship is required to purchase and 
carry numerous replacement parts and consumable items 
on its own. The ship is presently carrying an 
estimated one- time • expenditure of $475,000 in repair 
parts and is expending $100,000 per year in 
consumables to support the WANG VS-100. 

3 . Management I ssues 

In addition to those advantages and disadvantages 
enumerated above, there are several issues that do not fit 
clearly into either category. These are issues that should 
be considered before the decision to acquire and install a 
processing system is even made. For the most part they are 
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management issues of which only five will be addressed in 
this chapter. 

a. Need and purpose. Although the justification for 
installing the original System-20 on board the U.S.S. 
CARL VINSON was to satisfy a perceived need in the 
area of planning an control, a comcommitant purpose 
for the small WANG processor was never clearly 
defined. This failure to fix and control the specific 
applications that should be run on the WANG System-20 
resulted in its being used in several ways that had 
little to do with planning and control. To complicate 
the situation even more, the coterie of users was 
expanded to include the ship's department heads. The 
combination of expanding the number of users and 
allowing new applications to be placed on the system 
resulted in an increase in demand that was beyond 
the capability of the System-20 to fulfill. To meet 
these demands, the ship began a series of upgrades. 
Each upgrade replaced a predecessor that had failed 
to satisfy the ship's insatiable demand for 
processing, until the VS-100 was installed in July 
1981. If a thorough requirements analysis had been 
performed on board the U.S.S. CARL VINSON before the 
procurement of the first System-20, the true needs of 
the ship could have been recognized. This in turn 
would have resulted in a more efficient and effective 
method of acquiring a suitable processing system for 
the ship. 

b. Life Cycle cost. Prior to investing in an actual 
processing system such as the WANG VS-100, an 
economic feasibility study should be conducted in 
order ascertain if the system is too expensive for 
the benefits it will provide. This is usually 
determined by a thorough cost/benefit analysis. 
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There is no evidence that a cost/benefit analysis was 
ever performed on any of the WANG Systems installed 
on board the U.S.S. CARL VINSON. Two different 
members of the ship's management department made the 
comment during an interview that much of the software 
for the VS-100 was free, i.e it was provided by WANG 
when the system was installed. While initial cost may 
have been zero, the maintenance cost must still be 
considered. Another member of the management 
department indicated that consumable supplies (Disk 
packs, tapes, etc.) are costing approximately 
$100,000 a year. In addition, $475,000 in repair 
parts were bought for the WANG VS-100 during FY 1984. 
These parts were not used, but placed in storerooms 
in the event they are needed. These are just a few of 
the cost that should have been considered before 
system implementation. Although other cost figures 
were unavailable it would not have been difficult to 
work up a reasonable life-cycle cost estimate before 
making the decision to implement the system. The 
benefit side is much more difficult to quantify. In 
addition to the advantages discussed earlier in this 
chapter, the WANG VS-100 System has undoubtedly 
streamlined several operations on board the ship 
which has resulted in the savings of thousands of 
manhours. Some of these manhours could be quantified 
and translated into dollars, while others that cannot 
be identified result in improved administrative 
operations for the ship as a whole. It would not be 
unreasonable to find that the savings were actually 
as high or higher than the cost, 
c. Operational feasibility. This is concerned with the 
effect the system will have on the people who are 
going to use it, and in turn the effect the people 
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will have on the system. The effect that ship's 
personnel had on the expansion of the WANG Systems on 
board the U.S.S. CARL VINSON has been discussed 
throughout this Chapter. However, the effect the 

system had on ship's personnel and other systems is 
just as dramatic. For example, two major concerns in 
this area are job displacement and manning 
considerations. As of October 1984, there were 11 
personnel assigned to the WANG division within the 
management department. Three of these personnel were 
petty officers and two of them were designated 
strikers in the data processing rating. This means 
that six of the eleven personnel were recruited from 
other divisions within the ship to work in the WANG 
division, three personnel that had been assigned to 
the ship for the Snap program had been placed in the 
WANG division, and two personnel were either 
recruited from another division on board the ship or 
taken out of the ship's Snap II manpower complement. 
This raises an interesting question as to whether the 
Snap division on the U.S.S. CARL VINSON is being 
adversely affected by having five technicians that 
were originally assigned to the ship as part of the 
Snap I program actually working in the WANG division. 
Whatever the case, this type of manning decision was 
dictated as a direct result of the WANG's rapid 
expansion and lack of Navy manpower support for the 
WANG system. The issues to be considered under 
operational feasibility must therefore address the 
impact a particular system will have on other 
shipboard systems by creating an increased demand for 
scarce resources such as technical manpower, 
d. Security issues. Security issues must be addressed 
and dealt with throughout the life of the system. In 
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an environment such as exist on board the U.S.S. CARL 
VINSON, where sensitive and classified information is 
prevalent in virtually every department, security of 
information is paramount. The engineering department, 
which had originally been using the VS-100, has moved 
most of its files to a WANG PC to prevent a possible 
compromise. Likewise, the VS-80 System located in 
the combat information center is completely isolated 
to prevent the compromise of highly classified 
information . 

Security of unclassified information must also be 
considered. While the WANG VS-100 has an extensive security 
system that requires both a code and a password, besides the 
federated management system previously discussed, the 
system has two ways in which security can be bypassed. The 
first way is to obtain system administration rights. All 
members of the WANG division are granted these rights, which 
allows them to access any files within the system. To reduce 
the potential for abusing this privilege, certain 
precautions can be taken. One such precaution is to ensure 
that all personnel given system administration rights come 
under the purview of the Navy' s Personnel Reliability 
Program ( PRP ) . This is a program which certifies personnel 
who are required to work with sensitive information or 
equipment. It is not clear whether the PRP was used within 
the management department on board the U.S.S. Carl Vinson. 
The second way that unauthorized entry to sensitive 
information could occur is by monitoring the cables 
connecting the peripheral devices and terminals to the CPU. 
Since all cables connecting remote terminals or PC's run in 
open cableruns, often through unmanned compartments, they 
could be monitored at numerous points with equipment that is 
readily available on board ship. Using this technique, 
someone bent on malicious destruction or sabotage of 
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information could easily obtain the frequencies generated by 
authorized users logging into the system, and later 
duplicate these same frequencies to access files. Security 
is an issue that must be addressed before a system is 
procured, as well as, throughout its entire life-cycle. 

G. CONCLUSIONS 

The implementation of the WANG VS- 100 System on board 
the U.S.S. CARL VINSON was perhaps done too quick. Instead 
of doing a requirements analysis and then selecting the 
system, the system was selected and applications developed 
after the fact. While backwards, this method does have its 
advantages. The primary one is that it allows the user to 
experiment with novel ways in which to use the system. 
Sometimes a new and innovative application is developed that 
serves to justify system cost better than those applications 
for which the system was intended. 

Many of the disadvantages of the VS-100 are 
disadvantages only because the system is not standardized 
and supported by the Naval supply system. This is the reason 
the ship had to procure and stock repair parts costing 
$475,000. Had the WANG VS- 100 been a common system within 
the fleet supported by the Naval supply system, the ship 
would not have had to tie up so much money in repair parts. 

The WANG is a reliable system as demonstrated by its 
lack of significant casualties on board the U.S.S. CARL 
VINSON, but this very reliability could result in future 
problems for the ship. Personnel on the U.S.S. CARL VINSON 
are becoming too dependent on the system. As more 
applications are added to the system, it will become even 
more indispensable to the ship. On the other hand, as the 
system ages it will likely become less reliable. Parts will 
begin to wear or deteriorate and the system will likely 
experience increased downtime. 
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IV. SNAP 



A. INTRODUCTION 

The Shipboard Non-tactical Automated Data Processing 
Program (SNAP) was designed to provide surface ships and 
submarines of the U.S. Navy with a standard, information 
management system. This program has three primary purposes: 

1. Reduce the ever growing administrative work- load 
associated with maintenance, supply, financial 
management, and personnel administration. 

2. Provide a responsive, flexible facility for shipboard 
management . 

3. Improve the accuracy and timeliness of ships' reports 
to other commands, without increasing the ships' 
administrative work-load. 

The original goal of the SNAP program was to meet the 
Chief of Naval Operation's (CNO's) Objective Number 5 of 
1980. This objective was intended to alleviate "the 
administrative burden on fleet units." [Ref. 37] The SNAP 
concept has been developed as two separate programs. SNAP I 
for larger ships of the fleet, and SNAP II for smaller 
surface ships and submarines. 

1. SNAP I System 

The SNAP I non-tactical computer system is the 
replacement for the AN/UYK-5(V) system which has been in use 
in the fleet and in Marine Air Groups since the mid-1960's. 
SNAP I is designated the AN/UYK-65 ( V) , non-tactical ADP 
system. Eventually all the larger ships of the Navy will 
have SNAP I systems installed, including the carriers, 
repair ships, supply ships, and amphibious ships, and the 
Marine Air Groups (MAG) . 
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SNAP I started in 1974 when a plan was approved for 
the replacement and upgrade of the AN/UYK-5(V) system, which 
by then was obsolete and experiencing maintenance problems. 
A two stage implementation plan was finally approved in May 
1977. 



The first step included the replacement of several 
hardware units, including tape drives and line printers that 
had been experiencing many maintenance and operational 
problems. This step was completed in May 1980. The second 
step in the implementation process included the replacement 
of the remaining hardware with commercially acquired, 
off-the-shelf, processing equipment. This was paralleled by 
an upgrade in application software to handle on-line, real 
time processing. 

Honeywell Information Systems International Inc., 
was selected as the prime contractor for SNAP I in June 
1982. The Honeywell DPS-6 series computers are installed as 
a distributed processing system and are arranged in one of 
four basic configurations depending on the mission and type 
of each ship. [Ref. 38] A total of up to 221 DP-6 systems 
are to be purchased for installation on 67 ships, 17 MAGs, 
and 26 selected shore sites (SIMAs, training sites. Naval 
Air Stations, etc.) All the shipboard equipment 

installations are to be completed during fiscal year 1985 
[Ref. 39]. The projected life-cycle costs for the SNAP I 
system are estimated to be: 

1. Software Development Costs 

2 . Software Maintenance Costs 

3. Hardware Acquisition Costs 

4. Ship Alteration/Instal lation Costs 

[Ref. 40] 



$127,389,000 
$319,914,000 
$420,600,000 
$ 74,307,000 



By October 1984, seventeen of the eighty-five phase 
two equipment replacements had beed completed. Many of the 
real-time (RT) application programs were being tested in 
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fiscal year 1984 and were scheduled to be implemented during 
the following two years. Until these programs are ready, the 
AN/UYK-65(V) systems have been emulating the AN/UYK-5(V) 
computers, processing data in batch mode, with key to disk 
data entry. [Ref. 41] 

2. SNAP II System 

SNAP II systems are scheduled for installation on 
452 ships between the fiscal years 1983 through 1988. The 
basic philosophy behind SNAP II is to provide a system that 
is centrally procured, designed and managed, which can be 
operated and maintained by users who have little knowledge 
of computers. This is different from the SNAP I systems, 
which require a a staff of computer technicians and 
operators. The SNAP II systems are designed to be highly 
reliable, requiring a minimum of shipboard maintenance and 
repair. The premise underlying this concept is that no 
additional shipboard personnel are required for the 
operation and maintenance of the SNAP II system! Instead, 
personnel already assigned to the ship with appropriate 
technical backgrounds, i.e. Electronic Technicians (ET) 
will be trained to operate and maintain the system. They 
will perform these duties on a collateral basis along with 
their primary duties. Thus, SNAP II computers are designed 
to run without operators in an unmanned space, while users 
interact with the computer via remote terminals at various 
locations throughout the ship. 

The SNAP II systems use application programs written 
in COBOL, but allows the users to write and run their own 
programs in BASIC, MUSE IV word-processing language, or A2-7 
report/query generator language. The application software, 
provided and maintained by the Navy Management Support 
Systems Office (NAVMASSO), cannot be directly interfaced or 
accessed by user generated COBOL applications. This 
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limitation is intended to protect against intentional or 
inadvertent modification of the SNAP II application software 
and databases. 

The hardware used in the SNAP II systems, designated 
AN/UYK-62 ( V) , comes in one of four standard configurations 
depending on ship type and class. SNAP II systems use Harris 
series-300 minicomputers and other commercial 
"off-the-shelf" peripheral equipment ruggedized for 
shipboard use. 

While the SNAP I and SNAP II systems have different 
hardware architecture, they have similar software design 
specifications, with some of the application software 
capable of running on both systems with only minor 
modifications. The application software is designed and 
developed by the NAVMASSO, who is the Central Design 
Activity (CDA) for both systems. Because of these 
similarities in the management and functionality of the two 
systems, only SNAP II will be reviewed in greater depth . It 
is the design, development and management of this SNAP II 
system that is the focus of this chapter. 

B . BACKGROUND 

SNAP II systems are intended to provide the smaller 
surface ships and submarines with an automated data 
processing capability. 

One main problem faced by shipboard commanding officers, 
has been the ever-growing administrative and management 
burden placed on their ships. 

"The continued emphasis on decreased shipboard manning 
levels has traditionally addressed only the operational 
requirements and overall impact on shipboard combat 
readiness. The Commanding Officer, however, has few 
tools beyond personal leadership to cope with the 
administrative burden." [Ref. 42] 
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This problem has been the theme of several research studies 
over the past decade. The SNAP II system represents the 
culmination of that research for improving productivity in 
the fleet. 

1. The U.S.S. DAHLGREN Study 

In August 1972, the Chief of Naval Operations 
(OP-91) directed a study into the potential use of automated 
data processing on board combatant ships to support 

maintenance and material management (3-M), personnel 

administration, and supply. The U.S.S. DAHLGREN (DLG-12) 
was selected as the site for this study. [Ref. 43] The 

non-tactical ADP system installed and tested on U.S.S. 
DAHLGREN in January 1973 was a Data General NOVA 1200 
"minicomputer" with a 32k-word core memory, one printer, one 
teletype, a disk system, and four CRTs. The operating system 
supported a limited multi-user environment, which used a 
swapping mode of time slicing. It also supported the BASIC 
programming language. The application software developed 
and implemented during the study was Computer Integrated 
Instruction (CII) and Shipboard Training Administration 
System (STAS). CII was an online training program for 
shipboard instruction in General Damage Control, while STAS 
was used to manage a personnel training database system as 
well as a Personnel Qualification Standard (PQS) tracking 
system. Both systems were developed off-ship by Naval 
Personnel Research and Development Center (NPRDC) and 
installed and prototyped on board the U.S.S DAHLGREN. 
[Ref. 44] From the study report, issued in December 1974, 
four primary conclusions can be drawn: 

a. Commercial off-the-shelf hardware can effectively be 
used in the harsh environment of the small combatant. 

b. The off- ship development of software by the Navy 
Personnel Research and Development Center (NPRDC) 
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proved to be a highly effective method of providing 
high quality application software without increasing 
the work load for shipboard personnel. 



There were not 


enough 


CRT 


terminals 


and 


teletypes to 


adequately support 


the 


training 


and 


management 


applications . 












The use of 


computer 


systems 


for 


shipboard 



non-tactical applications was shown to be an 
effective means to improve productivity in damage 
control training and in training management. 

After several primary users of the NOVA 1200 system were 
transfered to other commands the system fell into disuse. 
As a result of this disuse and the lack of "command 
attention", the NOVA 1200 system was removed from the ship 
in December 1974. 

2. The U.S.S. GRIDLEY Study 

In early 1975, the U.S.S. GRIDLEY (CG-21) was chosen 
for a second study to be conducted under the direction of 
NPRDC. Using the Data General NOVA 1200 mini-computer 
system, NPRDC implemented 19 management applications that 
were previously developed for U.S.S. DAHLGREN. The programs 
were so successful that in 1978 the Data General system was 
replaced with a larger, more capable Digital Equipment 
Corporation, PDP 11/60 computer system. The new system 
supported Pascal, BASIC Plus, Fortran IV, and COBOL in a 
multi-user environment. Because the U.S.S GRIDLEY already 
had data systems technicians assigned in addition to the 
dedicated personnel working on the system, they were soon 
running ship developed applications, which included 
automating a 23,000 line item supply inventory, the crew's 
personnel records, and the Coordinated Ship's Maintenance 
Project (CSMP). [Ref. 45] 
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While several conclusions can be drawn from the 
lessons learned in the U.S.S. GRIDLEY study, one point was 
clear from the onset. Command "support and interest" made 
the difference between success and failure. Other 

conclusions of the study [Ref. 46], include: 

a. Shipboard personnel are capable of developing 

applications that effectively reduce the manual 
work-load, but the time required to do so is 
prohibitive, and the results are not of equal quality 
for all commands. The real payoffs come in the 
transfer of operating application software to other 
commands, without additional development costs. 

b. Off-the-shelf commercial hardware could be used to 
provide automated data processing on board small 
combatants despite the harsh environment of salt air 
and constant movement due to the ship's pitching and 
rolling . 

c. Major supply functions, like inventory material 
management of on board repair parts, could be 
maintained on hard disk drives, requiring only 3-4 
megabytes of disk memory. 

3. The U.S.S. COONTZ and U.S.S. RADFORD Study 

In March 1980, the Commander Surface Forces Atlantic 
Fleet ( COMNAVSURFLANT ) authorized a NPRDC study on the 
shipboard use of microcomputers for word processing and 
other data management applications. The U.S.S. COONTZ 

(DDG-40) and the U.S.S. RADFORD (DD968) were chosen as sites 
for the study. Alpha Micro AM-1031, microcomputers with 256 
KB main memories, and 16-bit central processing units were 
leased and installed. The systems included Winchester 10 
megabyte hard disks, video display terminals, and printers. 
All were connected with standard three pair shielded cable. 
A data management system, called AMS developed by Applied 
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Micro Systems LTD., and a word processing system, called 
ALPHAWORD, were provided with the leased systems. These 
systems used a multi-user, multi-tasking operating system, 
handling up to six users at a time. Power was provided by 60 
Hz voltage transformers. 

During the one year study there were no system 
malfunctions, even though both ships made extended six month 
deployments, subjecting the systems to high seas, 
temperatures of 85-95 degrees, and humidity between 75-85%. 
This demonstrated the high reliability of commercial, 
off-the-shelf hardware in the shipboard environment. Each 
ship had two maintenance men who had received only two weeks 
of training in system maintenance. [Ref. 47] 

Although more than 80 data management applications 
and 200 word processing applications were developed, there 
was a significant difference in the use of the Alpha Micro 
systems by the two ships. On the U.S.S COONTZ, the 
Commanding Officer became heavily involved, acting as the 
head systems analyst. He had his data systems technicians 
chief (DSC) spending 45% of his time on the system. The ship 
made extensive use of both the data management system (DMS) 
and the word processing systems. On the other hand, U.S.S. 
RADFORD assigned a data systems technician second class 
(DS2) to maintain and operate the system on a collateral 
duty basis. Although the word processing application was 
well used, few DMS applications were developed, 
demonstrating that the quality of shipboard software 
development is proportional to the amount of attention and 
support provided by the command. [Ref. 48] 

The conclusions of this study provided a valuable 
insight into the use of microcomputers for shipboard 
non-tactical automated data processing. The primary lessons 
learned were [Ref. 49] : 
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a. The use of computers has a significant impact on 
reducing the administrative work-load in the fleet 
and contributes to operational efficiency. 

b. Data management applications can be developed by 
shipboard personnel, but only with significant 
command support and manpower. 

c. Many commercially available microcomputers are 
reliable and compatible with the shipboard 
envi ronment . 

d. Six keyboard video display terminals (KVDT) provided 
with the systems were insufficient to adequately 
support data entry. 

Although the study was completed after much of the SNAP II 
planning had been done, it supported the viability of the 
SNAP II concept. It also addressed the need to deal with the 
proliferation of microcomputers in the fleet. 

4. SNAP 1 1 Concept Development 

In 1978, the conceptual idea of SNAP II was 

approved. The Mission Element Needs Statement (MENS) for the 
system was approved in May 1980. It outlined the requirement 
for an automated system to reduce the administrative burden 
on the fleet. The proposed program was to be a centrally 
managed and coordinated effort to provide non-tactical 
automated support to every ship in the fleet. The 

philosophy was that functional requirements and interface 
requirements were the "same" for all ship types,' even though 
the hardware requirements might differ. Therefore, a 
standard Management Information System (MIS) could be 
created around these same functional specifications. 
[Ref. 50] 

In 1979, the Automated Data System (ADS) development 
plan was written. It was reviewed by the various functional 
sponsors and fleet commands. Based on this ADS plan, SNAP 
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II was prototyped, using leased WANG VS-80 computer systems 
and peripherals, and application software developed by the 
Navy. The purpose of prototyping was: 1) to prove the 
viability of the SNAP II concept, and 2) to refine the 
"concepts and strategies preparatory to seeking authority to 
develop the Automated Information System (AIS)" [Ref. 51]. 

The Functional Description for the SNAP II, 
Shipboard Data System (SDS) was issued in March 1981, by 
NAVMASSO, with the overall goal of automating six primary 
functional areas. See Table II . 





SNAP II 


TABLE II 

Functional Areas 


1 . 


Supply 


4. Maintenance 


2 . 


Pay/Disbursing 


5. Personnel 


3 . 


Administration 


6. Medical/Dental 



Since SNAP II was designed to be run by users with 
minimal computer training, the decision was made to have the 
SDS operate on an interactive menu driven basis with on-line 
assistance available. Also, the databases were to be 
maintained and supported by an online mass storage (disk) 
system, with enough storage capability to hold the databases 
and still have enough reserve for future growth. 

The initial release of the application software was 
an attempt at going for the "quick victory" to gain support 
of the user communities, while later releases were to 
include greater depth and scope in the applications 
provided. The first release of SNAP II SDS was developed 
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concurrently with the hardware acquisition so that it would 
be operationly certified by the time of the first hardware 
delivery. [Ref. 52] 

One early problem encountered was getting 
concurrence on the functional specifications for the various 
SDS subsystems. This was primarily due to different 
procedures between the Atlantic fleet and Pacific fleet 
commands, as well as differences between ship types and 
sizes. The most difficult point to sell was that SNAP II was 
not just an automation of existing procedures, but rather a 
total replacement of existing procedures with an integrated, 
automated system. In the end, the functional sponsors for 
each of the subsystems designated the procedural 
requirements to be included in the initial release of SDS. 
In all, nine distinct subsystems were planned. See Table 
III [Ref. 53]. 





TABLE III 








SNAP II SDS Subsystems 


1) 


Systems Management 


6) 


Pay/Disbursing 


2) 


Corrective Maintenance 


7) 


Personnel 


3) 


Preventative Maintenance 


8) 


Admini stration 


4) 


Aviation Maintenance 


9) 


Medical . 


5) 


Supply Financial 
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5. 



SNAP I I System Acquisition and Selection 



In November 1981, the Naval Sea System Command 
issued a contract to Systems Management American (SMA) Inc., 
"for the acquisition and logistical support of the ADP 
hardware, software, and related services for SNAP II" 
[Ref. 54]. This contract was expected to exceed $200 
million over its 20 year life-cycle. It was issued to SMA 
as a Small Business Administration "8(a)" set-aside, which 
is part of a Minority Small Business and Capital Development 
program to "promote equal access to government contracts" 
for those who are both socially and economically 
disadvantaged [Ref. 55]. SMA Inc., is owned by Herman E. . 
Valentine, who is president and corporate chairman. In 1982 
SMA was ranked nationally as the 32nd largest, "black owned" 
company in the United States, with gross revenue of about 
$17 million. One year later, sales topped $31 million, with 
75% of the revenue from Navy contracts. This changed SMA 
national ranking to 17th. [Ref. 56] 

The Navy contract calls for SMA to act as the 
"system integrator" acquiring, ruggedizing, and integrating 
the computer system components. The acquisition of the 
system components was to be through a competitive selection 
process wholly controlled by SMA. The use of an integrating 
contractor for SNAP II had the advantage of reducing the 
extensive time delays and complexities of a major system 
acquisition, and gave the Navy a single contractor to deal 
with in resolving all hardware and system software problems. 

The SNAP II selection process was conducted by SMA 
in November 1981, with seventeen vendors submitting 
proposals. See Table IV for the list of bidders. [Ref. 57] 
The selection was made by "SMA's technical and managerial 
staff, augmented by consultants from private industry and 
Old Dominion University" [Ref. 58]. 
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TABLE IV 



Vendors Bidding on SNAP II 



Requirements 



C3 (Convergent Technologies) 
C3 (Perkin Elmer) 

CPT (Submarine Only) 

Data General 
Datapoint 
Digital Equipment 
Federal Data (TI) 

G. E. Aerospace 
Memorex 



Harri s 
Honeywell 
IBM 
WANG 

Electronic Marketing 

Hetra 

Mi ltope 

Wright Marketing 



By December 1981, the field had been narrowed to 
three proposals which had been selected for further 
evaluation. These included Data General, Harris, and 
Honeywell. All other proposals evaluated by SMA were deemed 
unacceptable. [Ref. 59] 

On December 23, 1981 SMA completed the evaluation 
process and announced the selection of the proposal bid by 
the Harris Corporation. The Harris 300 computer . systems had 
been selected for SNAP II even though they had never been 
used in any major business system applications. 

An interesting point here is that the functional 
specifications for the SNAP II system called for it to be 
fully compatible with SNAP I to allow the transfer data 
files between systems. Only a few months after SMA's 
selection of the Harris computers for the SNAP II system, 
Honeywell DP-6 computer systems were selected for SNAP I 
systems . 
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In January 1982, the performance validation testing 
was conducted on the proposed Harris system. The test 
results showed that the system was having problems with the 
Performance Validation Instruction Package Software. After a 
second revalidation test later that month only one 
discrepancy remained, which dealt with the interpretations 
of "response" and "response time" [Ref. 60]. The Harris 
system finally passed the benchmark tests in early February 
1982, with 20 successful runs and an average response time 
of less than 3 seconds, as called for in the functional 
specifications. From their evaluation and analysis of the 
work-load requirements and data available from NAVMASSO, SMA 
recommended memory requirements for the Harris 300 computers 
to be used in three different configurations: 

- small 384Kb 

- medium 768Kb 

- large 1 . 5Mb 

Since the Harris equipment is expandable to 3.0Mb, it 
appeared to meet the system specification requirements. 
[Ref. 61] 

In March 1982, the Commanding Officer of the 
Operational Test and Evaluation Force ( COMOPTEVFOR ) 

expressed concern about the hardware selected by SMA for the 
SNAP II system. After two demonstrations of the proposed 
hardware systems, it was clear that some of the 

specifications identified in the contractual Statement of 
Work (SOW) were not being met. The specific items identified 
included the following [Ref. 62], 

a. The system had an inadequate diagnostic system for 
system maintenance. 

b. The Harris 300 minicomputer had never been proven in 
a major business application. 

c. There was no uninterruptable power source to assure 
power during outages. 
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d. • The keyboard video display terminals were not 

provided with editing keys for text editing, or with 
user adjustable brightness/glare controls. 

e. The response times were slower than called for in the 
specifications . 

f. The system provided no "fail soft" protection for the 
subsystem levels of operation 

g. There was no word processing capability. 

h. The printers were all from different manufacturers, 
meaning that there was no printer family 
inter-operability and that there would be increased 
logistic requirements for repair parts. 

While none of the deficiencies cited by COMOPTEVFOR were in 
themselves insurmountable, they pointed out a basic problem; 
the hardware specifications defined in the Statement of 
Work, USN Solicitation N00024-81-R-7165 , were not being 
fully complied with by SMA. 

The Harris 300 series minicomputer had been modified 
to meet size requirements of the design specifications. This 
required changing the circuit boards from their original 
vertical configuration, to a horizontal position and 
reducing the ventilation space above the computer circuit 
cards. A direct result of this was: 1) the natural 

ventilation past the circuit cards was lost, 2) the circuit 
boards warped in the horizontal position causing them to 
make poor contact with their connectors, and 3) they 

presented an excellent surface for the accumulation of dust 
from unfiltered air, further reducing heat transfer from the 
boards . 

After extensive testing and evaluation, the first 
SNAP II system was installed on U.S.S SIDES (FFG-14) in 
January 1983 . 
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6. Operational Test and Evaluation of SNAP I I 

During the period of March 7-18, 1983, an 

operational assessment of SNAP II was conducted on board 
U.S.S. SIDES. COMOPTEVFOR described the system as 

potentially operationally effective, but not operationally 
suitable for shipboard use, and recommended that it not be 
approved for fleet introduction. [Ref. 63] During the test, 
designated OT-IIA, the SNAP II system was thoroughly 
evaluated according to the performance standards provided in 
the systems test plan. The results of OT-IIA pointed out 
several problems with the SNAP II system provided by SMA. 
[Ref. 64] 

a. The response time was slower than the design 
specifications. 

b. Any user could use job control language to change the 
ownership and attributes of the files in the central 
database, without setting off an alarm or leaving an 
audit trail to indicate actual or attempted entry 
into the restricted files. While the SNAP II system's 
data files are unclassified, the database does 
contain information covered by Privacy Act 
regulations as well as financial accountability data 
for disbursing, ships' store, food service, and 
supply management. 

c. The size and weight of the system installed on board 
U.S.S SIDES was far beyond the design specifications 
provided in the functional description. They called 
for a system which would be no larger than 26 inches 
wide by 60 inches tall (so it would fit through a 
standard hatch) and weigh no more than 130 pounds. 
The SNAP II system weighed an unbelievable 2257 
pounds and was mounted in a dual cabinet that was 26 
inches by 70 inches by 48 inches, thus presenting a 
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significant problem for installing these systems on 
submarines and smaller ships in the fleet. 

d. Unfiltered air was being drawn through the computer 
cabinets and keyboard video display terminals (KVDT), 
causing dirt accumulation on the circuit boards and 
internal components. 

e. The magnetic tapes and floppy disks produced on the 
SNAP I system could not be loaded into the Harris 
system. This data transfer was required for passing 
maintenance related job orders from the Current 
Ship's Maintenance Project (CSMP), as well as other 
supply related data. 

f. The system operator/coordinator considered the SNAP 
II system too slow, and not user friendly. This 
situation could only get worse as more application 
programs are added to SNAP II. Also, there was 
insufficient space for the users at the work stations 
and around the computer itself. 

g. The concept of providing system coordinators and 

maintenance personnel with only two weeks of training 
on the SNAP II system did not appear to provide them 
with a sufficient knowledge of the system and its 
capabilities. The users and system managers were 
unaware of a several functions and procedures 

available on the system. 

h. The non-standard keyboards provided with the system 

were difficult to use, even for an experienced 

typist . 

These issues, as well others, lead to the 

recommendation by COMOPTEVFOR that the Navy not procure any 
additional SNAP II systems until they have successfully 
passed an operational test and evaluation examination to 

ensure the system meets requirements. [Ref. 65] 
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Only two weeks before OT-IIA, the Naval Sea Combat 
Systems Engineering Station had conducted a First Article 
Test Afloat of the SNAP II system installed on the U.S.S. 
SIDES. This test was to verify the installation procedures, 
to establish a base line production configuration, and to 
verify many of the same functional requirements later 
inspected during OT-IIA. On March 1, 1982 they reported a 

successful First Article Test and recommended system 

procurement and implementation [Ref. 66]. Based on that 
recommendation, in May 1983, approval was granted for the 
procurement and installation of the first 40 SNAP II 
systems. Acquisition authority for the procurement of 
additional SNAP if systems was contingent on the successful 
completion of a second Operational Test and Evaluation, 
designated OT-IIB. 

The second operational test and evaluation for SNAP 
II (OT-IIB) was conducted on board the U.S.S. FAHRION 

(FFG-22) from October 17 to November 2, 1983, while the ship 
transited form Mayport, Florida to Rota, Spain. Once again, 
OPTEVFOR concluded that the SNAP II system was not 
operationally suitable for use in the fleet. This finding 
was based on the validation criteria provided in the SNAP II 
Test and Evaluation Master Plan 657 (CH-2) of August 8, 

1983. During the evaluation they noted that only 12 of the 

20 system discrepancies from the first test (OT-IIA) had 
been corrected. The SNAP II system problems noted during 
this evaluation included (Ref. 67], : 

a. The response time still exceeded the three seconds 
maximum requirement of the contract specifications 
often taking 30 seconds or longer to respond. 

b. The power backup system was not adequate, requiring 
the system operators to reboot the system after each 
power loss and reset the real-time clock. 
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c. 80% of the database applications could not view the 
data at the video display terminals, but could only 
provide hard copy printouts. 

d. The system ran without an operator 75% of the time 
( criteria : 90%) . 

e. SNAP II was still overweight and oversized, though a 
600 pound power supply had been removed from the 
system and the total system weight was reduced to 
1496 pounds. (OT-IIA system weight was 2257 pounds) 

f. The mean time between failures was 16.6 hours (OT-IIA 
was 43.1) while the criteria was established at 2000 
hours between failures. 

g. The external interface with the Radio Central message 
center did not work when paper tape message data was 
fed into SNAP II. 

h. The security system still gave a user with access to 
the job control language the ability to change the 
ownership and or characteristics of a file without 
setting off an alarm or leaving an audit trail. 

i. It was taking the maintenance personnel an average of 
three hours to find and repair casualties, based on 
eighteen trials (criteria: 45 minutes). 

j. The printers jammed as the ship rolled underway. 

k. Dirt still accumulation on internal circuit boards of 
the computer and KVDTs because of unfiltered air 
drawn through the systems. 

l. There was no room to lay documents near terminals 
while typing, and the MUSE IV word processor could 
not provide OCR documents. 

m. Changing circuit boards was extremely difficult 
because of the small amount of vertical clearance 
between circuit cards and most of interconnecting 
cables at the front of the cards. 
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The vision of an easy to operate/maintain, user 
friendly, highly reliable system was quickly fading. Many of 
the functions provided by the system were not used because 
of lack of on board expertise. Also, only a few applications 
were being programmed by on board users in BASIC or AZ-7 
query/report generator languages. 

The failure of the SNAP II system to pass the test 
and evaluation, OT-IIB, prompted Vice Admiral Baciocco 
(OP-098) to express his concern, and desire for a third 
operational test later designated OT-IIC. It was clear at 
this point that not all the functional design specifications 
provided in the contract with SMA could be met by the Harris 
Computer System. Also, the software provided by NAVMASSO 
would need a great deal more work, if all the application 
programs cited in the integrated functional description were 
going to be provided. 

In December 1983, the Commander of the Naval Surface 
Forces Atlantic (COMNAVSURFLANT ) consolidated comments from 
the thirteen ships of the Atlantic Fleet that had SNAP II 
systems installed. The command comments indicated an 
overwhelmingly positive response to the SNAP II system. 
While problems still existed with SNAP II, the users found 
it a significant improvement over manual processing. 

"All have praised overall system operation and 
effectiveness in achieving the program goal of reduced 
admin ef fort ... SNAP II has dramatically eased the burden 
on a minimally manned ship... is unequivocally 
recommended for fleet introduction." [Ref. 68 f. 

It seems a paradox for the system to be declared unsuitable 
for shipboard use and yet receive such strong endorsement 
from the shipboard users. The answer lies in the change from 
manual procedures to automated processing. While the 
statement of work (SOW) defined specific processing 
requirements, the users were just happy to have the SNAP 
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system on board, even if many of the functional subsystems 
of SNAP II were not working up to the technical design 
standards. The SNAP II system was providing the ships' 
Commanding Officers the tools needed to solve shipboard 
management problems. 

In March 1984, after a great deal of discussion, the 
Vice Chief of Naval Operations directed that the Master Test 
Plan for OT-IIC be modified to include only those "system 
requirements and characteristics required for fleet 
introduction." [Ref. 69] Only 45 of the 210, specific 
requirements, from the integrated functional description, 
were included in the revised test plan for OT-IIC. Many of 
the specific performance requirements had been eased. ( For 
example, the response time requirement was increased from, 
less than three seconds, to not less than 6 to 30 seconds 
depending on the situation. Also, the mean time for 
repairing the system during hardware failures was increased 
from 45 to 90 minutes. 

The third Operational Test and Evaluation was 
conducted in early May 1984 on board the U.S.S. Arthur W. 
RADFORD (DD-968). Of the 20 deficiencies from the previous 
test, 10 were still unresolved and of the 44 application 
software problems, only four were reinspected. The response 
times were still slow with an average of 7.7 to 11.5 seconds 
with various system loads, and a 41.9 seconds average time 
to sign-on the system. Most of those discrepancies from the 
previous evaluation OT-IIB remained, except for system 
security, which had been improved with software traps to 
prevent unauthorized or inadvertent access to system files. 
The system' s maintenance men easily passed the new standard 
of 90 minutes for making system repairs. 

Based on the findings of OT-IIC, COMOPTEVFOR, stated 
"If satisfying the requirements set forth in the revised 
Master Test Plan are adequate for supporting full 
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production, then operational effectiveness and operational 
suitability support recommendation for full production of 
SNAP II." [Ref. 70] 

The Deputy, Under Secretary of the Navy for 
Financial Management granted approval for full production of 
the SNAP II systems in June 1984, based on the findings and 
recommendations of COMOPTEVFOR from the third evaluation, 
OT-IIC. As of September 1984, 56 SNAP II systems had been 
installed on surface ships. The rate of installation was 
scheduled to be eight SNAP II systems per month until all 
452 ships are completed. One problem being encountered by 
the fleet commanders has been matching ships' operational 
schedules to the dates available for installation. This 
problem has been compounded by the lack of authorized Ship 
Alterations (SHIPALTS), which must be completed and 
authorized before installation of the SNAP II hardware. As 
of December 1984, only five of 38 SHIPALTS had been 
completed, representing 145 ships. [Ref. 71] 



C. ESSENCE OF SNAP II 

The SNAP II program was the second part of of a two 
phase program for modernizing and expanding the automated 
data processing capability in the U.S. Navy. SNAP I was to 
replace the AN/UYK-5(V) computer systems installed on the 
larger ships of the fleet since the mid-60s, while SNAP II 
was to provide an ADP capability to the smaller ships which 
were primarily non- automated . With the advent of large 
scale integration of computer components with their 
increased reliability and declining cost, it was now 
economically feasible to provide non-tactical computer 
systems to every command in the fleet. 
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The philosophy of the SNAP program was to provide every 
surface ship and submarine in the fleet with an automated 
data processing capability to support shipboard management 
and reduce the manual work load requirements on the crew 
used in processing data and directing shipboard activities. 
By centrally procuring the system hardware and software, 
logistic problems, training requirements, and overall 
life-cycle costs would be minimized. Each ship or submarine 
would have one of four authorized hardware configurations 
depending on ship class and type. These initial 
configurations give each command a base-line capability 
which can be expanded later. 

The primary gains from SNAP II, as reported by Pacific 
fleet commands include: 1) better use of assigned manpower, 
2) increased accuracy of data sent to shore support 
activities, 3) improved ships configuration management, and 
4) efficient administrative support. [Ref. 72] 

The SNAP II is made up of three primary systems joined 
together under the control of a Harris minicomputer. These 
include the hardware, the system software, and the 
application software. The hardware and system software are 
provided under contract with Systems Management American 
(SMA) Inc., while the application software is developed, 
designed, and installed by NAVMASSO in Norfolk, Virginia. 
NAVMASSO is also the central design activity for the SNAP II 
system. The application software is primarily written in 
COBOL, using a hierarchical modular design to improve its 
maintainabli ty and to support the introduction of later 
software releases and additional application program 
modules . 

The systems have on-line user manuals, documentation, 
and diagnostic systems providing the users and system 
operators with easily understood English-like information. 
This is necessary because SNAP II systems are designed to be 
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installed on ships that do not have ADP experts specifically 
assigned for running or maintaining the systems. Instead, 
each ship sends crew members to system coordinator and 
system maintenance schools, which are about two weeks in 
length. The individuals in turn provide the training for the 
rest of the users and functional area supervisors. 

The schedule for SNAP II installations runs through 1989 
and includes 472 sites, both afloat and ashore. The planned 
delivery schedule requires the installation of about eight 
systems per month during that five year period, and presents 
a scheduling nightmare matching available ships with 
installation teams, and authorized SHIPALTs. See figure 
4.1 [Ref. 73]. 

Based on the modified requirements from the OT-IIC test 
plan, SNAP II is now considered to provide: 

1. response times from 6 to 30 seconds 

2. mean time for component failure of 2000 hours 

3. less than five reboots per day 

4. mean time for repairing casualties of 90 minutes 

5. 85% system availability 

6. unattended operations 65% of the time 

The SNAP II system is limited to unclassified data and 
programs because of the stringent security requirements 
required to store and process classified data on a shared 
computer system. This limitation seriously restricts the 
amount of operational planning and reporting that can be 
done on SNAP II. A possible solution would be to use 
stand-alone Zenith 150 series microcomputers with 10 Mb hard 
disks which are TEMPEST certified for processing classified 
data, but no hard copy would be possible unless the printer 
was also TEMPEST certified. 

At the time of this writing, the Zenith 120/150 
microcomputers were well on their way to becoming a fleet 
standard. Because of delays in the development of some 
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Figure 4.1 SNAP Installation Schedule 

software applications for SNAP II, several application 
programs have been produced for the Zenith systems including 
retail operations, food service operations, and disbursing. 
These applications do not interface other parts of the SNAP 
II database and are thus appropriate for the stand-alone 
systems, especially since these are all areas of financial 
accountabi li ty . [Ref. 74] These application programs are 
not scheduled for implementation on SNAP II until after 
fiscal year 1986. 
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There has been much discussion about providing better 
system response time and up-grading the hardware for the 
SNAP II system. These areas are discussed in later sections 
of this chapter. Other future plans include using 
microcomputers to access the Harris computer, instead of the 
KVDTs now used. This would permit some of the processing 
functions to be off-loaded as well as providing the 
capability of running commercial software packages on the 
SNAP system. 

So far SNAP II has been well received in the fleet, with 
most commands concluding that the "economic benefits of the 
centralized system outweigh its limitations" [Ref. 75]. 
Other comments though indicate: 1) there is a general 
feeling that there are not enough KVDTs (at least two more 
needed), 2) there are some problems with circuit cards 
vibrating loose during underway operations, and 3) there is 
the need to power the SNAP II system with a "vital" power 
source, so it doesn't have to be shut down every time 
non-vital power sources are lost. 

1. SNAP I I Hardware 

The Automated Data Processing Equipment (ADPE) for 
the SNAP II system is designated AN/UYK-62 ( v) . It is 
provided by Systems Management American (SMA) Inc., under a 
Navy contract which requires them to purchase, integrate, 
and ruggedize the system components. The components are 
arranged in one of four configurations, large, medium, 
small, and small (submarine). See Table V [Ref. 76]. Each 
configuration is nearly identical, except for the number of 
peripheral units attached. 

a. Processor Subsystem 

The Harris 300 super-mini computer is the heart 
of the the SNAP II system. Ith uses a 48 bit word-size, plus 
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the address and control bits. Internal data is transmitted 
in parallel at a speed of 19.2Mb per second. The main 
memory is expandable to 3.0Mb, though the current SNAP II 
configuration uses only 1.5Mb of random access memory (RAM). 
With the addition of a 70 nano-second cache memory and the 
expanded memory, the system can be converted into a Harris 
500 computer, with operating characteristics similar to an 
IBM 370/158 computer. [Ref. 77] 

The commercial version of the Harris computer 
mounts in an equipment rack that is 80"high by 44"wide by 
32"deep and weighs 1050 pounds. The contract specifications 
for the SNAP II system called for SMA to provide a computer 
system that was proven in business applications, no larger 
than 26 inches wide by 60 inches tall (so that it could fit 
through a standard shipboard hatch), and about 130 pounds in 
weight (to meet small ship weight limitations). [Ref. 78] 
The SNAP II model of the Harris computer required 
significant modification of the "off-the-shelf" version, 
since it did not meet any of these criteria. At present the 
Navy's SNAP II system is the beta test site for 
modifications and changes to the Harris system hardware and 
software . 

Additionally, the central processing unit (CPU) 
of the processor subsystem includes the communication 
network processors, a power distribution system, and the 
programmers control panel. 
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TABLE V 



SNAP II Shipboard Conf i gu ra t i ons 



Equ i pment 


La rqe 


Med i um 


Sma 1 1 


Sma 1 1 ( sub ) 


Ma i nf rame 


Harris 300 Main Memory 


1.5 Mb 


1.5 Mb 


1 . 5 Mb 


1.5 Mb 


V i rtua 1 Memo ry 


12 Mb 


12 Mb 


12 Mb 


12 Mb 


Winchester 80Mb Hard Disk 


4 


3 


2 


2 


Nine Track Mag Tape Drive 


1 


1 


1 


1 


Paper Tape Reader/Punch 


1 


1 


1 


1 


Te rm i na 1 s 


User Te rm i na I s 


16 


8 


4 


1 


Operator Terminals 


1 


1 


1 


1 


Pr i nte rs 


300 LPS Line Printers 


2 


2 


1 


1 


Display Pr i nte rs 


8 


2 


2 


1 


Word Processing Printers 


4 


2 


2 


0 


Othe r 


8" Floppy Disk Drives 


2 


2 


2 


1 


Ca rd Reade r 


1 


1 


1 


0 
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b. Input/Output Subsystem 

The I/O Subsystem provides the primary interface 
with the SNAP II users. It includes display terminals, 
printers, and other I/O devices. 

The systems include KVDTs which have an 80 
column, 24 line display, and are capable of handling 
graphics . 

There are three kinds of printers provided with 
SNAP II, including: 1) display printers for making hard 
copies of KVDT screen displays, 2) line printers, which run 
at 300 lines per minute for volume printing jobs using 
continuous forms (5" to 16" wide) and 3) work processor 
printers for letter quality printing, capable of using a 
variety of different fonts. 

Other I/O devices include a paper tape 
punch/reader for the interface with the ships' communication 
center and a card reader for inputing supply requisition 
status cards provided by shore commands. (The tape and disk 
drives are listed with the storage devices.) 



c . 



Mass Storage Subsystem 



This subsystem includes the devices used to 
store the data and software programs for the SNAP II system. 
Since the SNAP II system is designed to run without an 
operator, most of the storage is on hard disks. The various 
configurations provide for two to four Winchester sealed 
hard disk drives, with four 8 inch disks and seven 
read/write heads. For system back-up there are 9-track 
magnetic tape drives, which run at an average speed of 75 
inches per second with a density of 1600 bits per inch. 
Finally, there are 8 inch floppy disk drives which are used 
to receive or provide data with external sources, i.e. SNAP 
I systems. 
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d. Power Subsystem 



The power subsystem is provided to ensure an 
orderly shut-down of the SNAP II system when there is a 
power failure. It includes four types of electrical 
line-filters, used to regulate the line voltage to the SNAP 
II system. 

e. Future Hardware Plans 

The future plans for ADPE improvement look 
promising, and should solve many of the early problems with 
reliability, speed and system size. These plans include 

1. expanding the Harris main memory and increasing the 
size of the virtual memory addressed by the operating 
system 

2. using denser hard disks to provide 160Mb per disk 
pack 

3. reducing both the size and weight of the components 
and the equipment rack 

4. increasing the number of terminals 

5. using portable microcomputers in place of terminals, 
fitted with hard disks and up to 600K of RAM, to 
allow off-loading of some applications 

A current listing of SNAP II equipment manufacturers and 
vendors is provided in Appendix A. 

2 . SNAP I I System Software 

SMA provides the system software for the SNAP II 
system. The system software includes the operating system, 
utility software, and compilers. The Harris 300 

minicomputer uses the Vulcan Operating System (VOS), which 
is capable of addressing 12Mb of virtual memory. VOS 
supports nine high level languages, including: 1) COBOL, 2) 

FORTRAN 77, 3) Pascal, 4) TOTAL DBMS, 5) AZ-7 query 
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language/report generator, 6) T-ASK information retrieval 
system, 7) APC, 8) SORT/MERGE, and 9) MUSE IV word 
processing language. Not all these languages are provided to 
the ships with the SNAP II systems. The shipboard version 
of SNAP II only comes with AZ-7, SORT/MERGE, MUSE IV, and a 
BASIC language compiler. Since the application software 
provided with the system is written in COBOL, shipboard 
users are not allowed to use COBOL. This is done to protect 
the programs and database provided with the system. 
(Ref. 79] 

Since the selection of the Harris computer for the 
SNAP II system, there have been problems with the operating 
system. The primary complaint has been that, 

"the current SNAP II system suffers from inefficiency in 
both run-time throughput and response time. Specifically 
shipboard users have voiced concerns regarding the 
excessive amount of time required to perform routine 
functions while utilizing SNAP II." [Ref. 80] 

The main difficulty lies with the operating system itself. 
VOS supports an indexed sequential file management system 
called VISP, which does not allow file sharing. With several 
users trying to access the same files, the system soon slows 
to a crawl. Other problems cited in one report provide an 
insight into some of the VOS problems. [Ref. 81] 

a. Alternate indexed files are not efficiently processed 
during read and write operations. 

b. There is no multiple character suppression in the 
indexed files, so large blocks of data must be moved 
between the record buffer in the server and the 
pseudo buffer in the application programs. This 
requires the operating system to allocate large 
blocks of dynamic memory, causing a significant 
degradation in the system response time. 
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c. The lack of multiple character (blank) suppression, 
also causes large amounts of disk space to be wasted. 

d. Because alternate-key data retrieval slows the system 
down so much, programs have been developed which 
artificially eliminate the use of the duplicate keys. 
This inturn increases the record size and complexity 
of the programs. 

e. The multi-user version of VISP seems only to be an 
kludge of the basic system. 

In July 1984 SMA announced a new release of the 
operating system, VOS 3.1.1, to address many of the issues 
discussed above. In particular, the new release would 
provide a new multi-user VISP package and multi-character 
blank suppression. That announcement led to the suspension 
of almost all new application software development for SNAP 
II, while the new operating system was being integrated. 
[Ref. 82] This caused a delay in software development of 
nearly eight months, until about February 1985. The new 
version of VOS improves the response time and performance of 
the SNAP II system. 

3 . SNAP I I Application Software 

The application software for SNAP II is designed, 
developed, and maintained by NAVMASSO. It has a modular 
design so that additional software releases and new 
application software modules can be easily added to the 
system. This significantly reduces the cost of software 
maintenance. The SNAP II Shipboard Data System (SDS) 
implementation has been broken up in two distinct phases. 
The initial release was designed as a first effort at 
reducing the administrative work- load on the ships, while 
the follow-on releases are phased enhancements of the basic 
system or new functional applications defined by the system 
sponsors . 
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SDS has four functional components in its design: 1) 
The System Management Subsystem (SMS) directs the overall 
operation of the application software for the SNAP II 
system. 2) The Organizational Maintenance Management 
Subsystem (OMMS) handles all administrative aspects of the 
shipboard maintenance program. 3) Supply and Financial 
Subsystem (SFM) manages the administrative functions of 
shipboard supply and inventory management. 4) The 
Administrative Data Management Subsystem (ADM) used in 
supporting shipboard personnel and administrative functions. 
Additionally, SDS accesses the word processing system 
software which has been described by the users as "easy to 
use " and a "real time saver". Figure 4.2 (Ref. 83]. shows 
the relationships of the primary four subsystems. 

a. System Manager Subsystem 

The SMS is the control module for the shipboard 
data system. It includes functions dealing with overall 
system management, system integrity, menu selection, on-line 
user manual, and queuing of reports. It is this menu-driven 
module that the users must first deal with when logging on 
the SNAP system. It not only provides system security, but 
also has the back-up and recovery modules required to ensure 
the integrity of the databases. A diagram of the major 
functions of SMS is displayed in figure 4.3 [Ref. 84]. 

b. Supply and Financial Management Subsystem 

The SFM subsystem provides the basic tools to 
eliminate much of the manual supply record keeping and 
reporting functions, as well as providing an extensive 
inventory management capability. As the systems are 
currently implemented, when maintenance data is entered the 
status of on board repair parts is provide to the user by 
SFM. If the parts are carried on board, documents are 
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Figure 4.2 Shipboard Data System (Initial Release) 

created to draw the parts from the ship's Supply Support 
Center along with the requisition documents necessary to 
order replacement parts. If replacement parts are not 
carried on board, the documents are created to order them 
from other activities, and the system tracks the status of 
those parts by work order number, and provides the status 
information to the user. The beauty of SFM system is that it 
also maintains the financial obligation accounting records 
required to manage the expenditure of ship's funds and the 
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Figure 4.3 System Manager Subsystem 
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consumption expense accounting records, needed for internal 
and external reports. Figure 4.4 shows the major functions 
provided by the SFM subsystem [Ref. 85]. 

When parts, consumeables , or services are 
purchased through the SFM system, the MILSTRIP data used in 
ordering them, is queued and later punched in message format 
on paper tape for radio transmission through the ship's 
communication center. This feature has saved countless 
man-hours and has significantly increased the accuracy of 
the MILSTRIP messages. SFM also provides access to the 
ship's Consolidated Ships Allowance Listing (COSAL) which 
includes lists of the repair parts and components for the 
equipment installed on board a specific ship. The automated 
COSAL is arranged by Allowance Part Lists (APL), which 
reflect the repair parts that a ship is supposed to carry on 
board to support repairs. One weakness of the SNAP II 
system, cited by many of the users, is its failure to 
provide an automated interface with shore commands that 
provide the APLs and the COSALs that go into the ship's 
COSAL database. In general, the COSAL data have not been 
accurate when first installed with SNAP II systems, and the 
updates and modifications have to be entered by hand, one 
part at a time using the KVDTs. This can be an incredibly 
slow process for an APL that lists a thousand repair parts. 
This interface problem has been addressed and will be 
resolved by 1986 when APL data will be provided to the ships 
on magnetic media. [Ref. 86]. There is a certain amount of 
duplication in maintaining the COSAL data in the on-line 
database, because separate paper copy must also be 
maintained, for periods of time when the SNAP II system is 
not operational. The functional modules of SFM are displayed 
in figure 4.4 [Ref. 87]. 
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Figure 4.4 Supply and Financial Management Subsystem 

c. Organisational Maintenance Management Subsystem 

OMMS is is intended to provide ships with an 
automated maintenance management capability. All 3-M 
maintenance actions are recorded on-line and merged with the 
ship's current CSMP . This data combined with repair part 
ordering and status from the supply subsystem can then be 
used in the planning and management of maintenance work. 
Because of this automated capability, an average of more 
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than 50 man-hours can be saved for each repair availablity. 
OMMS supports on-line entry and display of maintenance 
actions, as well as management reports and scheduling aids. 
It provides for work-package processing, work-load planning, 
and on-line ordering of repair parts'. The functional modules 
included in OMMS are presented in figure 4.5 [Ref. 88]. 




Figure 4.5 Organizational Maintenance Management Subsystem 
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d. Administrative Data Management Subsystem 

The ADM subsystem will eventually contain all 
aspects of personnel management and administration (except 
classified information management). The initial release of 
ADM included functions for monitoring personnel assignments, 
training, and career development. In addition the database 
supported by ADM is used to track health & morale programs 
and retention programs. The primary complaint from the ADM 
users has been the time required to maintain the files for 
ADM. The functions provided by the initial release of ADM 
are presented in figure 4.6 [Ref. 89]. 

e. Future Application Software for SNAP II 

Over the next three years, there will be 

additional application software modules added to the 

shipboard data system, as well as improved or modified 
releases of the existing programs. The present plan calls 
for the following application programs to be added to the 
system [Ref. 90] : 

Organizational Maintenance Management Subsystem 

- 3M for Helo Detachments 

- PMS Scheduling & Admin Support 

- Technical Publication Library 

- Test Equipment Support 



Supply and Financial Management Subsystem 

- Financial Management 

- Food Services 

- Retail Operations 

- Mobile Logistic Support Force 

- Supply & Financial Reports 



Administration Data Management Subsystem 

- Disbursing & Personnel Management 

- Medical and Dental Management 

- Training Management 
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Figure 4.6 Administrative Data Management Subsystem 
D. ADVANTAGES OF SNAP II 

If the success or failure of a shipboard non-tactical 
computer system is measured solely in meeting primary design 
goal, then SNAP II would have to be considered an 
unqualified success, since it has served to significantly 
reduce the administrative burden on the fleet. As the SNAP 
II system is further developed and deployed over the next 
several years, its success will become even more evident. 
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The eight points discussed below present some of the more 
significant advantages of the SNAP II system. 

1. Centeralized Development. SNAP II can be thought of 

as a centrally managed, geographically distributed 
processing system designed for the U.S. Navy. Each 
of the 452 planned nodes of this distributed 
processing system will be located on different Naval 
ships, but will have similar processing 

configurations. Under this view of the system, the 
functional sponsors and the fleet commanders act as 
the steering committee, making system management 
recommendations to the CNO . Therefore, the decisions 
on how to manage the SNAP II system take on a more 
global, priority and policy, oriented view, than a 
system acquired and managed solely by the direction 
of one ship. Goals are established for the system at 
a high level, which are appropriate to the scope and 
cost of a corporate Information System. 

2. Standardized System. The standardization that SNAP 
II brings the Navy will be far reaching in nature. A 
universal system such as SNAP II, results in many 
economies of scale over the system's life-cycle. The 
training requirements for users is minimized, because 
every system is functionally the same. When an 
individual has been trained on the SNAP II system, 
and is then assigned to a new ship, there is a direct 
transfer of his knowledge and skills. Both software 
and hardware can be managed so cost of changes and 
modifications are minimized.** One can only imagine the 

/ 

chaos that would result if a major change in 
administrative procedures was required, and every 
command had to rewrite their application programs to 
incorporate the change. With a "single system" you 
don't reinvent the wheel each time a problem must be 
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solved. Instead the SNAP II concept provides a 
single point for the resolution of all problems. 
NAVMASSO serves in this capacity. 

3. Improved Logistic Support. The logistics of 

providing world-wide support for a standardized 
system like SNAP II are obviously much simpler and 
more cost effective than attempting to provide for 30 
or 40 different systems. Each ship will carry its own 
repair parts and expertise in maintaining the SNAP II 
systems, yet will be able to provide assistance to 
other ships if needed. Repair parts will be stocked 

^ in depth and not breadth, i.e. this allows the supply 
system to procure and stock parts that fit all 
systems vice unique parts for each system. This 
results in better inventory management and economies 
of scope. 

4. Increased Accuracy. The increased accuracy, in 
reporting parts usage for both corrective and 
preventive shipboard maintenance, provides the Navy's 
material managers with the necessary data to improve 
inventory management. As a direct result the COSALs 
will more accurately reflect the ship's equipment 
configuration. This leads to better supply support 
and consequently improved fleet readiness. 

5. A Management Tool. The manpower savings in going 
from a manual system to SNAP II, have been 
significant. While SNAP II does not provide many 
"bells and whistles", it does provide each command 
with the basic tools needed to manage shipboard 
administration, without requiring the assignment of 
additional crew members who are expert in the system. 

6. A Control Mechanism. The SNAP II system has had a 
unifying effect on the entire U.S Navy. By providing 
a "single system" for all the ships, policy and 
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procedures have been standardized. No longer will 
there be the "air" Navy, the "surface" Navy, the 
"sub" Navy, and the "Atlantic and Pacific" Navies, 
all with different rules and procedures for 
maintaining records and processing reports. Now 
there will be only one system ... SNAP ! It provides 
the commanders of geographically disbursed 
organizations with an excellent control mechanism to 
enforce standards and implement policy. When a change 
has to be made in administrative procedures it needs 
only be developed as a software modification and 
released to the fleet. 

7. Acquisition Strategy. One main advantage of the SNAP 
II acquisition methodology is the use of a prime 
vendor who sub-contracts, assembles, and integrates 
all the ADPE components and systems software. This 
allows the Navy to use one point of contact for 
addressing and resolving all system problems. 

8. Contractor Leverage. The use of a small contractor, 
such as SMA or Harris, offers a distinct advantage 
over many larger contractors. When a contract such as 
SNAP II, makes up a significant portion of their 
total business, they tend to be much more responsive 
to the unique needs of the Navy in scheduling, 
modifications and other such concerns. 

E. DISADVANTAGES OF SNAP II 

The disadvantages of the SNAP II system can be argued 
from the point of view of the Commanding Officers and what 
it provides them in the way of a flexible management tool. 
Many of the traditional management issues of shipboard 
command involve the solving of dynamic, unstructured 
problems, that are not always supported by "canned programs" 
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provided by standard, management information system. The 
points that follow present some of the disadvantages of the 
SNAP II system from this prospective. 

1. System Inflexibility. The application software for 
SNAP II is designed so the shipboard user cannot 
access the databases with locally generated programs. 
While this is done to protect the integrity of the 
information stored in SNAP II, it incorporates 
inflexiblity in a system that must also respond to 
dynamic changing needs. It makes little sense to 
limit the users to Basic, when Pascal and FORTAN are 
also supported by VOS. Also, without a dedicated 
SNAP II expert assigned to each ship, it is unlikely 
the fully potential of the system will ever be 
realized . 

2. User Dependence. A growing dependence on the SNAP II 
system may not be evident until a major casualty 
occurs to the system. Such a casualty could result 
from anything from malicious destruction to wartime 
damage. This dependency is a huge liability because 
an architecture with a single CPU and little fault 
tolerance has been chosen for SNAP II. Unless manual 
procedures are reheresed and practiced on a routine 
basis, the ability to function without the computer 
may be quickly lost. Besides, hard copy COSALs and 
microfiche listings of repair parts, as well as 
technical manuals must still be maintained. 

Lengthy Implementation. 
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i 

/'-implementation process 

V 

situation where there 



The slow development and 
for SNAP II creates a 
are have's and have-not's. 
Those ships where systems have been installed can 
exploit its usefulness and profit from improved 
management of people, time and money, while those not 
scheduled to receive system for several years are 
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like second class citizens relegated to operating in 
the manual mode. This, along with the usual problems 
with application backlogs has led to the 
proliferation and use of microcomputers in the fleet. 
Some applications scheduled for implementation on 
SNAP II, have already been programmed for the 
stand-alone microcomputers and are meeting user 
needs . 

4. Classified Data. The issue of handling classified 
data in an automated environment was discussed 
earlier in this chapter. Since a good deal of 
shipboard information is of a classified nature, the 
issue must be addressed in meeting the information 
needs of the ships. At the present, SNAP II does not 
address this problem, other than to say that 
classified data will not be processed on the system 
without specific approval and appropriate security 
measures . 

5. Contractor Vulnerability. As a result of the 

acquisition process, SNAP II is being integrated and 
provided by a small company whose primary business is 
that Navy specific contract. Also, the computer 
hardware comes from a company whose computers are 
primarily used by the Navy. This results in a 
situation where the government almost has to 

guarantee the success and continuance of these 
companies, to maintain the viability of the SNAP II 
systems. If they were larger corporations with 
established track records for performance, the risk 
of them closing their doors and going out of business 
would be greatly reduced, i Once SNAP II is in place, 
users will grow to depend on the system and the 
information that it provides. The Navy will not be 
able to afford the disruption and expense of 
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the 



developing another system. Fortunately, 
application software has been developed so that it 
can be transported to other hardware systems. 

6. Increasing system scope. Since new capabilities are 
often added to computer systems under the guise of 
software maintenance, the scope and complexity of the 
systems are constantly increasing. This situation is 
no different with SNAP, causing the programs to look 
as though they are growing without bounds as the 
maintenance tail of the life-cycle curve continues to 
widen, giving the perception of poor management. This 
makes it extremely difficult for those who must argue 
for funding the SNAP programs. 

F. CONCLUSIONS 

The SNAP systems have been developed as a tools to make 
better use of available shipboard manpower, to increase the 
accuracy of the information used in managing the Navy, and 
improve the quality and level of support to the fleet. These 
are issues that relate to the readiness of the U.S. Navy in 
meeting its commitments and in fulfilling its mission. The 
research, planning and development that was completed before 
SNAP II ' s implementation have led to its success in meeting 
these goals. 

The philosophy of using a "single system" to meet the 
information and administration management needs of the Navy 
provides many interesting results. Not only are the systems 
life-cycle costs controlled, but also almost every aspect of 
providing logistics, training, and managing operations, are 
simplified. An additional and important feature provided by 
the "single system" concept is that of control. The 
standardization of procedures and policy, throughout the 
Navy as a result of SNAP I and SNAP II, could never have 
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been realized under a less centrally developed and managed 
system. Once fully implemented in the fleet, SNAP II will 
provide a mechanism of control never before possible under 
the manual system. 

The primary risk inherent in systems like SNAP I and 
SNAP II, is the users growing reliance on the information 
and data stored on the computers. In a war time environment 
it is likely that there will be periods of time when the 
crew has to function without the SNAP computer system. 
Therefore, the capability to operate in a manual mode must 
be maintained if that risk is to be minimized. While the use 
of a system with a single CPU may make some sense in the 
business world, it poses some strategic problems to a war 
ship that is geographically separated and must rely on the 
information stored in the database. 

Finally, while the acquisition process of major systems 
is not be perfect, it is the process we have to work with in 
the government arena. When a contract is bid on a lowest 
cost basis, you get what you pay for. The only mechanism to 
ensure that the system provides product that is needed, is 
through the accurate and specific design specifications. 
This is where the prototyping of the makes such a 
difference. Get the requirements "right" before contracting, 
and then stick with the specifications where they make 
sense. The objective must be in "getting the right 
system... and getting the system right." [Ref. 91] 
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V. CONCLUSIONS AND RECOMMENDATIONS 



A. CONCLUSIONS 

The systems discussed in this thesis have illuminated a 
spectrum of technical problems and managerial issues that 
should be addressed before introducing non-tactical 
computers into the shipboard environment. For example, the 
Perq minicomputers suffered many technical problems on board 
the U.S.S. Carl Vinson, because the hardware was neither 
designed nor specifically ruggedized for the oftentimes 
harsh shipboard environment it had to operate in. If the 
operational environment had been thoroughly examined before 
installation of the Perq computers, then different hardware 
might have been selected, or at least appropriate protective 
devices can be installed installed that would have minimized 
some of the equipment casualties that were experienced 
during the 1983 cruise. SNAP II, on the other hand, 
experienced several technical problems because design 
specifications were initially not adhered to i.e. size, 
weight, etc., or because they were changed to match 
equipment capabilities e.g. response time. Some of the 
managerial issues that should be considered if an 
implementation is to be successful include manning, 
security, applications, and the speed with which the system 
should be implemented, to name just a few. 

Both the Perq and WANG systems, as installed on the 
U.S.S. Carl Vinson, demonstrate some pitfalls that can 
occur if implementation is done too fast and without the 
benefit of a thorough requirements analysis. In each case 
the wrong machines were initially installed. The Perq's were 
not hardy enough, and except for the VS-100, the WANGs were 
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not large enough. The SNAP system on the other hand, has 
suffered from a long, drawn-out implementation process, 
primarily because of the extensive procurement process 
required for compliance with public law 89- 306 regulations, 
often called the Brook's Bill. While the conceptual idea for 
SNAP was approved in 1978, only 56 of 452 planned 
implementations were installed as of October 1984. This slow 
process results in the SNAP design being constantly altered 
or adjusted to take advantage of new technology, or to 
correct deficiencies in the original design. This means the 
first units installed will have to be back-fitted with these 
design or operational changes to maintain system 
standardization . 

Although the Perq computers suffered from equipment 
reliability problems, they did demonstrate the advantage of 
having a distributed processing capability. Despite 
casualties to several of the Perq computers during the 
U.S.S. Carl Vinson's 1983 cruise, the network was never 
completely disabled because of equipment redundancy. This 
redundancy is not provided for on either the WANG VS-100 or 
Harris SNAP II systems, because of their single CPU 
architecture. The risk of total system failure due to 
electrical power problems, malicious damage, or sabotage is 
therefore much higher in these systems than on the network 
of Perqs. 

The term non-tactical is misleading, because it connotes 
a system of secondary importance. For shipboard non-tactical 
automation nothing could be farther from the truth. With 
applications such as the supply-maintenance interface, 
intraship communications, and general word and data 
processing, these non-tactical computers are becoming more 
critical to the everyday operations of the ship. As more 
applications are developed for these non-tactical computers, 
both system dependency and the penalty for system failure 
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increase in magnitude. Along with these increased 
applications the risk of a sudden and devastating capacity 
crunch becomes much higher. This is what happened on the 
smaller WANG systems before the VS-100 was installed. The 
Wang System-20, System-30, and VS-80 were too small to 
handle the ever increasing demands placed on them by the 
ship's users. Whenever a new system was installed it would 
reach its capacity limit, resulting in a discernible 
slow-down and the inability to satisfy the many new 
applications that were being developed by shipboard users. 

Another area that must be closely looked at is 
life-cycle cost. This includes the original cost of the 
equipment, as well as operating and maintenance cost for the 
life of the system. Oftentimes, the original equipment cost 
is the least expensive part of the life-cycle cost. For 
example, a WANG VS-100 super minicomputer with 8 input, 
output processor interfaces, a 16 port serial I/O processor 
controller, a macroassembler, and one archive processor is 
listed for approximately $72,000 on current Federal Supply 
Contract schedules. Other vendors can supply comparable 
equipment at similar prices. Of course, when you start 
adding the cost for hard disk memory, terminals, printers 
and other peripheral equipments, the price rapidly 
increases. The majority of an information systems cost is 
spread throughout its lifecycle as maintenance, repair 
parts, wages for operating personnel, and software. These 
costs can exceed the original purchase price within a short 
time. Although the WANG was specifically used in this 
example, these cost hold true for any computer system. 

While the WANG installation on the U.S.S. Carl Vinson 
has proven the feasibility of using off-the-shelf, 
commercial computer equipment in a shipboard environment, 
the Perq has demonstrated the necessity for choosing the 
equipment wisely. This equipment should include overload 
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protection, • line protection, and the availability to operate 
at different ambient temperatures if a suitable controlled 
environment cannot be provided. 

B . RECOMMEND AT I ONS 

1. Before developing or purchasing a non- tactical 
computer system, regardless of size, a cost/benefit 
analysis should be conducted. This will help identify 
total life-cycle cost, as well as assist in 
identifying or justifying the need for such a system. 

2. A requirements analysis should be conducted before 
committing to a system. This will help in deciding 
whether an information system should be purchased, 
and if so which one. 

3. Both hardware specifications and site preparation 
must be well-thought out and defined before actual 
procurement of a system. They should address 
appropriate power requirements such as line filters, 
overload protection, and an uninterruptable power 
supply, as well as size and weight constraints, 
special environmental requirements, and security and 
safety considerations for both personnel and 
equipment . 

4. Where available, both commercial hardware and 
software should be procured and used. 

5. The user should drive application development 
whenever possible. Use of a fourth generation type 
language such as Nomad, Focus, or similar commercial 
products allows the user to develop his own 
applications. This is conducive to innovation, while 
also minimizing costly software development. 

6. Ensure that system architecture is flexible enough 
to allow for growth and incorporation of new 
technology. 
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7. 



A shipboard non-tactical computer system should be 
developed under the same philosophy as other critical 
equipments onboard ship, i.e. redundancy. One way to 
do this is to use a distributed network whenever 
possible . 

8. To encourage user innovation the system should have 
some excess capacity that can be used for locally 
developed programs. The SNAP concept does this, but 
uses the basic language instead of a more flexible, 
more user friendly language. 

While these recommendations do not in themselves 
guarantee a successful system implementation of a 
non-tactical computer system, they reflect some successful 
aspects of the Perq, WANG, and SNAP II systems, which should 
be considered when designing computer systems for the fleet. 
Research programs like Perq/ZOG and commercial systems like 
the WANG have a definite place in the Navy, and should be 
continued, because of the ingenious and innovative ways in 
which they are used. These creative ideas can then be 
transfered to the more standardized systems like SNAP. As we 
view the future, we must continue to look for ways to use 
new technology to increase productivity in the fleet. 
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APPENDIX A 



SNAP II MANUFACTURERS AND VENDORS 



Device 


Manufacture 


Vendor 


CPU 


Harri s 


Harri s 


Mass Storage 


Winchester 


Harris 


KVDTs 


Harris 


Harris 


Prog I/O Channel 


IPOC 


Harri s 



WP Printer 


NEC 


Bartlett Associates 


Line Printer 


PRINTRONIX 


PRINTRONICS 


Display Printer 


MPI 


Engineered Control Systems 


Paper Tape 


REMAX 


Harri s 


Card Reader 


DOCUMENTATION 


Harris 


Streaming Tape 


CIPHER 


Harri s 


Floppy Dsk Drive 


INSTOR 


Harri s 



116 



APPENDIX B 





GLOSSARY OF TERMS 


ADM 


Administrative Data Management Subsystem 


ADP 


Automated Data Processing 


ADS 


Automated Data System 


ADPE 


Automated Data Processing Equipment 


AIS 


Automated Information System 


APL 


Allowance Part Lists 


CCOL 


• 

Compartment Check Off List 


CDA 


Central Design Activity 


CIC 


Combat Information Center 


CII 


Computer Integrated Instruction 


CMU 


Carnegie-Mel Ion University 


CNO 


Chief of Naval Operation 


COSAL 


Consolidated Ships Allowance Listing 


CPU 


Central Procession Unit 


CRT 


Cathode Ray Tube 


CSMP 


Coordinated Ship's Maintenance Project 


DARPA 


Defense Advanced Research Agency 


DCA 


Damage Control Assistant 


DMS 


Data Management System 


DS 


Data Systems technicians 


ET 


Electronic Technicians 


FMS 


Federated Management System 
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GSA 


General Services Administration 


I/O 


Input/Output 


KVDT 


Keyboard Video Display Terminals 


MAG 


Marine Air Group 


MB 


Megabyte 


MENS 


Mission Element Needs Statement 


MIS 


Management Information System 


MPDS 


Message Processing Distribution System 


NAVMASSO 


Navy Management Support Systems Office 


NPRDC 


Naval Personnel Research and Development Center 


OMMS 


Organizational Maintenance Management Subsystem 


ONR 


Office of Naval Research 


ORSE 


Operational Readiness System Evaluation 


PC 


Professional Computer 


PLAD 


Plain Language Address 


PROMIS 


Problem Oriented Medical Information System 


PRP 


Personnel Reliability Program 


POS 


Personnel Qualification Standard 


RAM 


Random Access Memory 


RT 


Real-Time 


SBA 


Small Business Administration 


SDS 


Shipboard Data System 


SHIPALTS 


Ship Alterations 
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SFM 

SMA 

SMS 

SNAP 

SORM 

SOW 

SPICE 

SSTG 

STAS 

UPS 

VAC 

VISP 

VOS 

ZED 



Supply and FinancialManagement Subsystem 
Systems Management American 
System Management Subsystem 
Shipboard Non-tactical ADP Program 
Ship's Organization and Regulations Manual 
Statement of Work 

Scientific Personal Integrated Computing Environment 
Ship' s Service Turbo Generators 
Shipboard Training Administration System 



Uninterruptible Power Supply 



Volts Alternating Current 
VOS Indexed Sequential Package 
Vulcan Operating System 



ZOG edit 
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